Jump to content

X7123M3-256

Members
  • Posts

    1081
  • Joined

  • Last visited

Everything posted by X7123M3-256

  1. IIRC, that demo does contain all the assets (though I've not been through the whole list to check). It's time limited, but that won't apply if you use it with OpenRCT2. The demo linked on the Github page is missing objects, but I think that's a different demo.
  2. I tried that. You can get two sides to match, but the remaining sides then come out wrong. I tried using line search and gradient descent to minimize an overall error function, but I was not able to fit the data well, and even when you have a side that matches by the numbers, the visual appearance is often very different. I've pretty much given up with trying to get the lighting to look remotely decent.
  3. RCT2 cannot use true color images, so they will be converted anyway. I think the problem is that your lighting is way too dark. IIRC, the object editor doesn't dither, so it will pick the closest palette color. The dithered image is a better approximation of the actual color of the model, but it does look noisy when given a shade that doesn't have a close match in the palette. You can try turning dithering off if you'd prefer, but I'd say the light needs to be brighter anyway. Lighting is really difficult to get right, and at this point I've pretty much given up trying.
  4. I have no idea what you've managed to do there, to be honest, but here's what I did: start with the true color image (which is most likely what you are rendering). Open that in RGB mode, then go to Image->Mode, and select "Indexed". Then select the pallete you got from the screenshot, and set "dithering" to "Floyd-Steinberg". That should convert the image to indexed color.
  5. You can find RGB values for the game palette here. (I link this and not the OpenRCT2 source because they assign different values to the remap colors - OpenRCT2 will give you orange colors for the primary remap, but most tools expect green. I'm not sure of the reason for the difference - it doesn't really matter, but consistency would be nice) However, there's a much easier way: open any RCT2 screenshot in GIMP and then navigate to the palette window. It will show you the current palette, and you can save it for reuse. This will not give you the primary remap colors (they are all shown as black), but as mentioned above, you don't need them for this anyway. There are a few other palette values you need to exclude when converting images for use in game. The water colors and the chain lift colors will animate, which is probably not what you want. There are a few other values whose purpose I don't actually know. The colors you want to include are in blocks of 12, from dark shades to light shades.
  6. Sure. The primary remap colors are palette indices 243-254 (0xF3-0xFE in hex). The secondary remap colors are indices 202-213 (0xCA-0xD5) and the tertiary remap colors are 46-57 (0x2E-0x39). The primary remap colors are used only for remapping and never appear in game, so you should exclude them from your palette. There are also non-remappable greens, so this does not mean you can't have green areas, but if your object contains green areas and it's remappable then you'll have to work a bit harder to avoid them getting mixed up. The secondary and tertiary remap colors are only remapped if the object is remappable, so there's no need to remove them from the palette - they should show as the expected colors if they are not remapped.
  7. This was the main reason why I wrote my own renderer. However, there is another approach, which will work fine for objects which are entirely non-remappable (as here), or objects that are almost entirely remappable. The solution is to simply remove the remappable colors from the palette you use when you convert the image to indexed color. The only time this doesn't work is if you have remappable areas and also non remappable areas in the same color. I saw one approach based on splitting the image into two, palettizing with different palletes and then recombining them.
  8. Note that the primary remap colors never appear in game (they are always remapped to another color before being rendered), which makes their actual color somewhat arbitrary. Just about every RCT2 tool (including the object editor) uses green for these remap colors, but OpenRCT2's own sprite importer uses orange. If you are making sprites to be added to g2.dat, that's something to be aware of.
  9. Absolute limit is 10000 sprites, but coaster cars and vomit/litter are included in that. I have been unable to spawn more than about 9600 guests. This limit cannot be increased without a new save format.
  10. OpenRCT2 requires RCT2, not RCT1. You should point it at the directory which contains the rct2.exe executable and the subdirectories "Data" and "ObjData". The "Data" folder should contain the file "g1.dat" and several files of the form "css<number>.dat", and the ObjData folder should contain a large number of DAT files with names in all caps.
  11. Oh, OK, I understand now. That's... really strange. I have no idea what 3DS max is doing there, but that is definitely the correct projection. I think the simplest way to set the correct scale is to make a single square, and then make it the size that you want a tile to be (which seems to be arbitrary, anything between 3 and 4 metres is a reasonable value). Then adjust the camera until the image is 64 by 31 pixels, as this is the size of the tile sprites in gam.
  12. Yes, of course. Blender works the same way, even if the camera is orthographic it still has a 3D position. But with an orthographic projection, the distance doesn't matter, so you can just choose whatever value is convenient. Your projection does look correct, so I'm not sure why you're finding that the distance matters - are you sure you're not using a perspective projection with a long focal length? An orthographic camera does not have an FOV (or perhaps another way to think of it is, an orthographic projection is a limiting case of a perspective projection as the FOV angle tends to zero). If you use a perspective projection, the field of view looks like a pyramid, and the FOV angle is the angle that the sides make with with each other. With an orthographic camera, those sides are parallel. Here's a picture I found that illustrates this:
  13. These appear to be two screenshots taken at different zoom levels. That is not moving the camera, it's rescaling the sprites, so it shouldn't be surprising that it changes the size of the sprites. In fact, RCT2's "camera" only stores two coordinates, so there's no way to change it's z coordinate, it doesn't even have one (since it would do nothing). If the game was using a perspective projection, then placing two pieces of scenery, one towards the back of the visible area and one at the front, would result in two different images because one is further from the camera. Now, if the projection you're using is not the correct one then it's close enough that I can't tell the difference, so if you are using a perspective projection it must have a very long focal length. It looks to me like your camera is set up correctly, but if you are finding that the distance matters then it definitely isn't. This property of an orthographic projection is the reason you can't look inside a building, and why you can get confusion where two roof pieces appear to connect but are actually in completely different places. A game like this would not work with a perspective projection - similar games with a perspective projection are all rendered in real time. Sorry, I think I might have confused you a bit - you have to render the background of the sign, the scrolling text is what gets inserted automatically.
  14. The distance of the camera from the object should not have any effect on the scale of the image. If the position of the camera has any effect besides translating the image, then your projection is wrong - only the orientation is important. If the object looks smaller when the camera is further away, that's a perspective projection. Large scenery is a seperate object type. (I've never used the object editor so I really don't know if it's supported, but if the option doesn't seem to be there, it's possible that it isn't. I expect someone else will know one way or another). Entrances are another object type. The only thing you need to bear in mind when making multi-tile objects is that each sprite can only occupy one tile; you will need to split your sprites up. This can be done by splitting up the model and rendering three images.
  15. With an orthographic projection only the angle matters. An orthographic projection is equivalent to transforming the scene into camera space then dropping the z coordinate. It doesn't matter what the z coordinate was because you discard it. If you find that moving the camera further away changes the image, your projection is not orthographic. This is the reason the game uses an orthographic projection in the first place - if it had perspective projection, you would need a different sprite for every possible object position. No, that text is added by the game, you don't need to render it.
  16. I know nothing of 3DS Max, but are you sure those settings are for the camera and not the viewport? If those settings are for the camera, why do you have "top" selected? Wouldn't that position the camera to look down the vertical axis? A dimetric projection is an orthographic projection where 2 coordinate axes are equally foreshortened. I gave you the angles to use, if you have the camera set up like that (which it looks like you do) then your projection must not be orthographic. Try rendering a cube - that will make it immediately apparent if your projection is orthographic or not. It's the model that needs to be made taller, nothing to do with the projection. If you change the scale you'll make it taller, but you'll also make it wider and it's pretty much the right width already.
  17. Are you sure you're using an orthographic camera? In your image, the entrance doesn't line up with the tiles properly (look closely at the bottom corners). An incorrect scale would not cause this, either your view angle is wrong or you are using a perspective projection. The easiest way to test that would be to render a wireframe cube - if the projection is orthographic, all lines that are parallel in 3D space are parallel in the image. You're forgetting that RCT2 uses a dimetric projection, not isometric. If you are going by the height marks on the terrain, then size of a tile should be 1.5√ 6m≈3.674m . However, do note that RCT2 doesn't use consistent units throughout, so you are to some extent free to choose a scale. I use the height marks and stick to that; I do not trust anything from the ride stats window as they disagree not just with the measurements used elsewhere in the game, but with each other. Changing units should not change the ouput at all as long as you use the correct conversion between them, and even if you get that wrong it cannot be the cause of the misalignment, because this would just make the image larger or smaller, not change angles. Internally, RCT2 does not use metric or imperial - horizontal distances are measured in fractions of a tile and vertical distances are measured in fractions of a clearance. I sometimes find it useful to work in these units (because it scales out all the irrational numbers from the projection), but I mostly use SI units. You can set the game to use SI in the options (I think this was an OpenRCT2 addition).
  18. For the camera angle, it should be angled 30 degrees down and then rotated 45 degrees about the vertical axis. If it is correct, horizontal lines should have a 2:1 gradient on screen.
  19. It'd need some pretty hefty supports to stand up in a flood. Moving water is extremely powerful, and even if the structure holds up, the foundations can be rapidly eroded away.
  20. You can hack the speed faster. I had implemented a console command for it but it never got merged.
  21. 1) I don't believe so, but what documentation exists is on Github 2) Max platforms per ride is 4 3)As many as will fit in the shortest platform, but never less than the minimum specified in the DAT, and not so many that the friction would be reduced below a set threshold. The absolute max is 255.
  22. I'd say a queue line should be long enough to fill two trains. A queue line that can't accomodate a full train of passengers will lead to the ride running under capacity, and you want it a bit longer to absorb variations in the rate at which guests arrive. But anything longer than that is pointless - once you have the ride running at full capacity, all a longer queue is going to do is make guests complain. Of course this goes mostly for scenario mode - in a sandbox park you would generally build whatever would be a typical length for that queue IRL.
  23. Fresh doesn't mean still, it means it's not salty. Lakes are usually freshwater, because they are continuously replenished by rainfall, but this isn't always the case. Some lakes have no outflow, so they lose water primarily by evaporation. Dissolved salts do not evaporate so they become concentrated in the lake.
×
×
  • Create New...