Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by X7123M3-256

  1. If using a renderer without support for orthographic projection, a workaround is to move the camera very far away and zoom in very far. This will give you a projection that's close to, but not quite, orthographic.

    I've done all the modelling for my rides in Blender, and I find it does the job well. I don't render my rides in Blender (I use my own renderer), but I've used Blender for rendering other sprites, and as long as you get the projection right and turn off anti-aliasing the results are good. Realistically, pretty much any 3D renderer can be used - you don't need any sophisticated features for this.

    If you are doing a scenery object and only have a couple views to render, you can always draw them by hand. I don't recommend this approach, but it's an option.

  2. I've never seen another swimming pool ride but that doesn't mean there's definitely not one ... is there something specifically wrong with AE's? The only thing I can think of is that the peep model isn't that great, but then, that's true of pretty much every custom ride.


    Also be aware that METRTUBE.DAT does not export correctly even in OpenRCT2... I still haven't figured out why.

  3. A couple of points about AE's tutorial:

    •  Don't render to a GIF and then convert to RCT2's palette. You're palletizing the image twice - the resulting quality loss is evident in several of AEs rides. Render first to true color, and then convert. I wrote my own renderer to handle the process, but that's probably overkill.
    • When you are converting to indexed color, if your object is supposed to be remappable don't include the other color indices in the target palette. Otherwise, you might end up with non-remappable colors in remappable areas. AE suggests touching it up manually. I don't - it will get very tedious if you are doing a ride as they have lots of sprites. Also, the colors that AE marks as remappable aren't actually the remappable ones. I wrote my own renderer to handle all this for me but that's probably overkill depending on how many sprites you need to render (some of my rides have tens of thousands).
    • Don't just guess the camera angle by trial and error. It's a well known projection that was/is common in "isometric" games (it is not however a true isometric projection). There's no need to guess, it, I have the projection matrix and the angles you need to set the camera to if you want them.
    • AE says several things are hardcoded that are not actually hardcoded at all. You can change the spacing of cars, you can increase the number of riders per car, you can add extra sprites, you can change the makeup of the train and really anything else except the track style and sound effects (there's other hardcoded stuff, like splashes, but it's not as frequently encountered). Flat rides are far more limited, because the animation sequence and base size are hardcoded, but still, I would recommend actually checking whether something can be changed if you need to.

  4. I don't have any experience doing custom scenery (yet), but I've done a number of custom rides. I can give all the information I have if you need it. I have information on the format of the .DAT files (though the OpenRCT2 source code is by this point probably the best resource for this), the palette you need to use, the angle that the camera should be set at, the correct scale for the game, and all the angles that you need to render sprites at (for rides mainly ... with scenery there's only 4 angles)

  5. The problem with including female peeps (or any other variations on the peep model), is that presently every ride has it's own peep sprites. If you add female peeps, you double the number of sprites you need for the ride... except you don't, because peeps are currently paired up. You would either have to have a sprite for every possible pairing, or have individual sprites for peeps instead. Either way, you now need four times the peep sprites per ride. Also, the peeps are so small you could barely tell the difference between male and female anyway.


    I would also like to see swimming pools properly implemented, but I don't think it will happen any time soon. I don't think it's a bad idea, but it would still need the base graphics to be extended with sprites for peeps wearing swim clothes, and some slight alterations to the object format, at the minimum.

  6. I have no experience with trainers as I've only ever used OpenRCT2 for hacks, and so I don't know exactly how the train length cheat that trainers provide is implemented. Trainers can only change memory values, not the code, so it's definitely not done by patching out the check like I did.

    In vanilla, the maximum train length is recalculated repeatedly whenever the ride window is open, so I doubt that just changing that value alone would work. When I did it in vanilla I would modify the minimum train length in the object file, which was the only way I found to force the maximum to be increased - otherwise, the station length and minimum friction are pretty much hard limits. If you do this with a trainer though, remember to reset the minimum after you've built your ride or the object won't export properly.

    In vanilla and all current versions of OpenRCT2 (except my patch), there is a hard limit of 16 cars (including zero cars and invisible cars, which don't show in the in-game car count). Attempting to bypass this limit will corrupt memory and most likely crash your game.

  7. OpenRCT2 still depends on RCT2 code which is x86. You can compile OpenRCT2 for ARM, and that has been done, but the result is unplayable because all the RCT2 code is missing. Therefore there's no point in anyone providing ARM binaries at this point. 

  8. It's not hard to create a reversed version of a train, because you just need to reorder the existing sprites, not render any new ones. In fact, I would probably just write a script to take a DAT and produce one with reversed trains automatically. However, there's so many DATs out there that I'm not just going to make a reversed version of every DAT I find unless someone specifically requests it, or I need it for a park.

  9. RCT2 does not clear the screen after each successive frame, because normally every pixel on screen includes at least one sprite (even outside the map boundaries, the game is actually drawing black tiles), so the whole screen gets overwritten anyway. If something causes sprites not to be drawn where they should, you get strange effects because the image from the previous frame is not cleared, it's simply drawn over the top of.

  10. 14 minutes ago, Broxzier said:

    We're using UDP, so there's no need for keeping track of IDs. Packets are guaranteed to arrive in the same order they are sent

    I'm confused. UDP doesn't guarantee that packets arrive in order - it doesn't even guarantee they will arrive at all.

  11. Most cheats are a button or a checkbox. This is a bit more involved, since you have to select the track pieces you want to move and the amount to move them by. It could go in the cheat window, but I think it would  be easiest to put it in the tile inspector because the tile inspector already shows element heights, it just doesn't have a means to change them. It would be just two buttons.

  12. 2 hours ago, BlazingEmpireHD said:

    Scenery checks, are not allowed if you are trying to get an edge over your opponents

    What is this supposed to mean? Everyone playing OpenRCT2 has this feature available (unless you're playing a really ancient build) so it doesn't give an unfair advantage, unless you mean "over rides that don't use zero clearance", in which case, why not just disallow it entirely? Do you mean to say that zero clearance is allowed only for aesthetic purposes and not for track merging  or other hacks? If so, why not say so?

    And what are the criterion by which the entires are judged? If it's judged partially on it's appearance, then wouldn't making the ride look nicer be an advantage by itself?

  • Create New...