mkruer

That seems a bit sketchy, but I do recall that the original RTC was programed in assembly so there was have been some sort of sorcery on the back end. RCT only stores the one sprite correct per object and that sprite is then downscale when the zoom goes out correct? So would it be possible to reverse it for the closet zoom to pixel double the sprite instead? This should have the same overall effect as setting the window scale factor to 2x. The only downside to this approach would be that the UI would be very small. The game would be using the full sprite at Zoom level 3 and not 4. Zoom Level 4 would be an 2x upscale of the original sprite Level 4 (128x64 standard sprite) @ 2x Level 3 (64x32 standard sprite) @ 1x Level 2 (32x16 standard sprite) @ .5x Level 1 (16x8 standard sprite) @ .25x Just thinking off the top of my head.

I came across this topic Suggestions to make OpenRCT2 prettier back in April, 2017 The idea was to visually improve the graphics, but at the time I think it was suggested to replace them with higher resolution sprites. Maybe a different approach might be possible as if there is a way to separate the sprite from the UI. I don't know if this would if freezable and looking for some clarification on the issue. To make sure we are all on the same page, I am defining; Zoom; internal to the game Scale; Add into OpenRCT2 for large monitor support By default, the zoom levels are Closet Level 4 (64x32 standard sprite) Level 3 (32x16 standard sprite) Level 2 (16x8 standard sprite) Level 1 (8x4 standard sprite) Farthest Is there a was a way shift all the levels by one but keep the UI elements default 1:1 based upon the original zoom? Closet Level 4 (64x32 standard sprite) @ 2:1 Zoom Level 3 (64x32 standard sprite) @ 1:1 Zoom Level 2 (32x16 standard sprite) @1:1 Zoom Level 1 (16x8 standard sprite) @1:1 Zoom Level 0 (8x4 standard sprite) @1:1 Zoom Farthest In the original thread it looks like the UI was the issue in that it somehow tied to the view and is not be its own element. Is this whats happening.

While it would likely be very complicated to implement, I'd love to see the ability to save terrain alongside the track and scenery. This would fix the issues where some rides cannot get imported easily because the terrain is too low to support the track or in other cases where there is a lot of dips inside the ground. Even if this was a destructive import, wiping out anything in the area, it would still be worth it, and then come back and fix those sections the import destroyed.

Share this for posterity. This was my final update to the original RTC1 Mega Park. I never had a chance to go back and revisit it after RTC2 came out and unfortunately do to compatibility issues between RTC1 and RTC2 I was unable to move migrate it. With OpenRTC2 that’s no logger a problem. The best feature IMO was the Monorail systems that I put in palace, tracks that took visitors around the park. Each quadrant was to be its own themed land. Mega Park Version 6v.SV4

Is this because the sv4, sv6 formats save the tile and/or sprite data inside the file itself? Just curious because as long as we kept the 1:1 mapping then i would not think it would be too difficult to export the save as an older format. I also noticed that with the OpenGraphics project OpenRTC2 is going with blender models. I guess that would be another way to do it. Thanks for the additional info

In RTC1 and 2 we are currently limited to 4 isometric view angles . Is it possible, assuming the graphics were available, to add in the in between angles? This would create an additional 4 directions 0, 45, 90, 135, 180, 225, 270, 315. For coasters at lease some of the tracks might be usable as there is already 45 tracks in game. I know this is a long way off but I came across the topic below, and instead of having someone create a one shot image for higher resolution graphics it might be worth while to use a free voxel editor like (https://goxel.xyz/ or https://www.voxedit.io) and create a 3d version that can be rendered out in any multiple angles.The creation of the voxles could be crowed sourced. We would just need to have an a agreed standard (grid size), sprite structure, hit list and some type of rendered to verify all the parts will work together.