Jump to content

openrct3?


goanna678

do you want it?  

41 members have voted

  1. 1. do you want openrct3?

    • yes
      23
    • no
      18


Recommended Posts

Not right now or anytime soon, because the devs will have their hands full with OpenRCT2 for quite a few years.  If you have a group of friends that can code well and reverse engineer code, get on GitHub and start your own OpenRCT3 project so you don't have to wait. ;)

Link to comment

I would love to see OpenRCT3, and even an OpenRCT1 too. I could imagine doing an OpenRCT3 would be exceedingly more difficult as RCT3 is 3D and RCT2 is not. 

 

Doing OpenRCT3 and succeeding at it would likely be a huge viral hit for this entire subject. 

 

If OpenRCt3 happened, and did well, I could see it going viral and fast.

 

I do think it's a cool idea, and I think it could work, it would take much longer though.

Link to comment

RCT2 is as 3D as RCT3 is, it is just viewed from a 2D perspective, remember the drawing functions are being decompiled seperately from the other code. If you want to know the reason why it's more difficult than RCT2, read Broxzier's post. OpenRCT1 would eventually result in exactly the same game as OpenRCT2 will be in the end, the starting point is just different, most likely making it harder to reach that.

Since professional companies already try/tried to improve RCT3 (with a different name ofc) or excel in a specific part of it, I don't think there's much need to start OpenRCT3.

Link to comment

Give the developers a break already! They have taken on a huge project in reworking the game we all love. I imagine that some of them are wondering what the hell they have gotten themselves into. This work is tedious, frustrating and time consuming and takes LOTS of patience. Let's enjoy what they have already done so far and wish them continue success!!!!!

PS: My company that I sold upon retiring did beta testing of telephone system voice mails on LINUX as they reversed engineered the ones which were designed for windows 2000. The end products were far superior to the windows ones with practically no breakdowns but this took almost 2 1/2 years.

I think the end OpenRCT2 will be spectacular with something for everyone.

  • Like 1
Link to comment
2 hours ago, jensj12 said:

My argument is as valid as yours. Both aren't that hard to add to the game.

Why would we even want to go back into RCT1? They are almost as identical? Would be better to add features to RCT1 into OpenRCT2

Also, you could always start your own OpenRCT1 development :)

Link to comment
On 7/25/2016 at 13:29, jensj12 said:

RCT2 is as 3D as RCT3 is, it is just viewed from a 2D perspective, remember the drawing functions are being decompiled seperately from the other code. If you want to know the reason why it's more difficult than RCT2, read Broxzier's post. OpenRCT1 would eventually result in exactly the same game as OpenRCT2 will be in the end, the starting point is just different, most likely making it harder to reach that.

Since professional companies already try/tried to improve RCT3 (with a different name ofc) or excel in a specific part of it, I don't think there's much need to start OpenRCT3.

RCT2 is not "as 3D as RCT3". RCT2 thinks of each object as a set of 4 sprites (for each of the 4 isometric views north/south/east/west), while RCT3 thinks of each object as a set of polygons in space. That said, it would not necessarily make it harder to create an openRCT3. @Broxzier was correct that it woulr probably be easier to create an RCT3 "mimic" from scratch than to create an openRCT2. OpenRCT2 essentially works by changing the code that is used to run the game, in conjunction with the resource files. RCT3 is coded differently and would take much more time and effort to decompile and edit.

  • Like 2
Link to comment
5 hours ago, YoloSweggLord said:

RCT2 is not "as 3D as RCT3". RCT2 thinks of each object as a set of 4 sprites (for each of the 4 isometric views north/south/east/west), while RCT3 thinks of each object as a set of polygons in space.

RCT2 (and presumably RCT3 too) thinks of each object as a (set of) map element(s). These are converted to one of the four corresponding sprites in the drawing routine. Someone made a 3D viewer for RCT1 by simply showing these map elements as 3D objects instead of simple sprites. If someone could do the same for RCT2 (creating 3D images for everything AND changing the drawing code), we'd have a 3D RCT2.

Link to comment
6 hours ago, jensj12 said:

RCT2 (and presumably RCT3 too) thinks of each object as a (set of) map element(s).

In RCT3 objects are represented by actual meshes, there is no pre-rendering and no use of sprites. The need to split objects across multiple map elements is gone because you have a depth buffer (I have no idea how RCT3 stores the map, but it certainly doesn't need to do it the way RCT2 does). While you can argue that RCT2 is a 3D game since the objects have coordinates in three dimensional space, the sprites themselves carry no depth information and the rendering techniques are closer to what you would see in a 2D game than something like RCT3. The image RCT2 produces is the same as what you'd get if you replaced the sprites with 3D models, yes, but in order to make that so the game has to be designed around certain restrictions:

  • The impossibility of correctly sorting objects for rendering using the painter's algorithm forces the objects to be organised into a grid, and objects that take up more than one grid square have to be split up into multiple sprites to avoid violating the constraint. To dispense with the grid you'd have to use an expensive topological sort, and you would get rendering glitches in cases of cyclic dependencies. Without any depth information, you can't resolve this problem - that's why you can't just place objects anywhere in RCT2 and why circumventing these restrictions with zero clearance will frequently cause rendering glitches. In RCT3, this restriction is artificial - there's no fundamental reason you should be confined to a grid.
  • You are limited to one viewpoint. To get the other four viewpoints, the object has to be rendered from four angles. You could add more viewpoints at the cost of rendering more sprites but there is no way to change the viewpoint arbitrarily.
  • You cannot use a perspective projection, because then you wouldn't be able to pre-render a sprite even with a fixed viewpoint - the object is distorted according to it's position in relation to the camera. A consequence of this is that RCT2 can never have a first person viewpoint.
  • Real time lighting isn't possible. The implementation floating around is a post-process where pixels near a light are brightened - it doesn't properly shade objects and it cannot computer proper occlusion or shadows.

 

  • Like 1
Link to comment

They're prerendered sprites from 3d models.

This same style was originally going to be used for Yoshi's Island, but was dropped soon after. This is why the intro looks different from the rest of the game.

Edited by imlegos
Link to comment
On 7/28/2016 at 06:03, jensj12 said:

RCT2 (and presumably RCT3 too) thinks of each object as a (set of) map element(s). These are converted to one of the four corresponding sprites in the drawing routine. Someone made a 3D viewer for RCT1 by simply showing these map elements as 3D objects instead of simple sprites. If someone could do the same for RCT2 (creating 3D images for everything AND changing the drawing code), we'd have a 3D RCT2.

In case anyone was wondering, here is the github for RCTGL (the 3D viewer for RCT1). Unfortunately, the original creator died unexpectedly, and the coding was uploaded to github by a friend of his who doesn't understand the coding (this is explained in the description at the bottom of the page.) I haven't looked into it, but if I had to guess I'd say that the original owner probably made a completely new sprite for most sprites in the game (track pieces, scenery items, etc.), and that these sprites were made as 3d objects or simply planar sprites that could be read by the 3D renderer, which then constructed an RCT1 map based on the XYZ coordinates in its .sv4 file. Either way, my point is that it is impossible/extremely difficult to create a full-functioning 3D viewer for RCT1 or RCT2 that only uses the .dat files used by RCT1/RCT2. Any full-functioning 3D viewer that allows for free movement and perspective would need files for each object's polygons and textures. You cannot "simply show the map elements as 3D objects instead of simple sprites," because the .dat files do not contain enough information.

Link to comment
  • 10 months later...
Guest
This topic is now closed to further replies.
×
×
  • Create New...