openrct3?

[goanna678]

title says

I don't know what to put in the description.

[cascadia]

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.

[Broxzier]

It'll probably be easier to recreate all features instead of reverse engineering RCT3. The reason it works for RCT2 is because the game was originally written in assembly.

[BlazingEmpireHD]

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.

[jensj12]

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.

[CharlieP]

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.

[imlegos]

Openrct1 would probably be less then ORCT2, as there is no shift key use in RCT1

[jensj12]

13 hours ago, imlegos said:

Openrct1 would probably be less then ORCT2, as there is no shift key use in RCT1

OpenRCT2 would probably be less than OpenRCT1, as there are no traffic lights in RCT2.

[imlegos]

If you mean the close/test/open lights, there is.

We already have that moded in using custom themes.

There's a preset for RCT1 in it.

[jensj12]

Read my previous post (with quote) again carefully and think about it. My argument is as valid as yours. Both aren't that hard to add to the game.

[Nubbie]

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

[YoloSweggLord]

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.

[jensj12]

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.

[imlegos]

RCT1/2 graphics explanation:

http://www.chrissawyergames.com/feature3.htm

[X7123M3-256]

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.

 

[imlegos]

Can we just end this with "RCT2 uses Prerendered 2D graphics, similar to Donkey Kong Country (SNES), while RCT3 uses 3D models"?

[Broxzier]

Donkey Kong country is a 2D game though, the background just scrolls slower when the view moves, but there's no Z axis, only X and Y.

[imlegos]

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 July 28, 2016 by imlegos

[YoloSweggLord]

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.

[NiklasBaum]

Please can somebody make RCT3

Kann bitte jemand RCT3 machen 

[Broxzier]

You're not even reading what others have posted here.

[NickBishop12]

i would love to c orct3 but most people said rct3 sucks well half yes and half no cuz it has more options more rides etc but they should definitely add new multiplayer so yea i would agree to c if they agree too 

[janisozaur]

Can someone please lock down this thread already?