Rendition card

[Pavel 69]

Oh, great to hear that detailed carshape can be loaded but also pity that texture size may be a problem. This carsetst use 256x328 pixels mips for cars. If 256 is already a problem than it's sad. But what is the source of the problem: limitation in rendition game's exe or wrapper?

[jxeboy]

Oh, great to hear that detailed carshape can be loaded but also pity that texture size may be a problem. This carsetst use 256x328 pixels mips for cars. If 256 is already a problem than it's sad. But what is the source of the problem: limitation in rendition game's exe or wrapper?

I did notice while trying to use this high-poly carset that fewer of the custom tracks load. For example I get the "insufficient memory" error with mid-ohio as well. So I wonder if the card itself is limited to 4mb like real life and most addon tracks use far more than that.

[Pavel 69]

But 4MB is too small amount even for original game files I think. But who knows.
Overall my Mid Ohio is very light track closer to original one. Because it uses mostly graphics from default track. So I'm not surprised it load in rendition game.

[checkpoint10]

I am working on understanding why my Detroit track is giving a "Problem loading track" error. I found that the version I posted in May 2022 works, but the one from September doesn't work.

Between those two versions, I added more buildings and trees, and changed the color palette.

[checkpoint10]

I rebuilt Detroit by eliminating all the trackside objects, and it loaded in Rendition. I will plan to bring the objects back - area by area - until I find what is causing the "Problem loading track" error.

I also found issues with textures:
- Some wall textures are being drawn as 64x8 textures rather than 64x16. These are the mips that I had as 1024x16, but I had used the MRK to split them into 64x16 or 128x16 depending on the spot on the wall. I guess it doesn't matter if you're using a small snippet of a wide mip - if the entire mip is wide, then it won't work.
- Some wall textures that have mips 512x16 wide - they work okay in the game.

[checkpoint10]

I am bringing back each "neighborhood" of objects, one by one. As I mentioned in another thread, Detroit is made of TSOs that are really groups of individual TSOs. For some reason, some neighborhoods are producing the "Problem loading track" error and some don't. I don't know of a pattern yet, because the ones that work have included the pit straightaway which includes some buildings with textures, the TSO of hundreds of people, and trees. They all look great. However, it got tripped up by a few TSOs that included bigger textured buildings.

[samsepi0l]

............Detroit is made of TSOs that are really groups of individual TSOs...........

This is my new preferred method as well. I especially used this in LBEACH91 because drawing order was very complicated in the infield section. I like this method because I can dynamically change the drawing order based on viewer position using BSPA's.

[checkpoint10]

After spending a bit of time making various edits to Detroit, I note the following:

- "Problem loading track" is most likely an insufficient memory problem.
- There were no single buildings or neighborhoods that had a specific problem being drawn, as long as textures were within reasonable sizes (i.e. no more than 256px wide)
- I may be having issues more easily due to detroi91.3do itself already taking up 752kb, leaving not much space for other things.
- My crowds 3do are anywhere from 20kb to 84kb and they add up fast, assuming they are loaded into the card's memory. People totaled 459 kb, or nearly 1/3 of all 3DOs. Despite the size, remember this was no issue on the vanilla DOS - they had almost zero performance impact due to being untextured.
- Total .3DO size including track and TSOs is 1.5 MB.
- Total MIP size is 3.82 MB. You can see that combined with .3DO, I am already exceeding 4 MB which is the size of some Rendition card memory. The wrapper may be emulating 4 MB.
- The game doesn't load the same MIP into memory twice, if used in two separate 3DOs. When I was on the verge of having memory issues, I replaced a new texture with an existing texture, and the track loaded okay.
- Total PMP size is 116 kb (trees). Trees looked absolutely fantastic - the high resolution really brings out the detail.

[samsepi0l]

I know for a fact that some of the vanilla tracks in even ICR1 needed more than 4MB to run. I upgraded from 4mb to 8mb ram in the early 90s. It cost me nearly $400 as a young teenager and I had to mow nearly every single lawn on my street just to play Laguna Seca and Elkhart Lake because I was getting the "insufficient memory".

Personally- I'm not going to worry about rendition. If they get it right- and our stuff works as is that's great. If not, then that's OK too.

[jxeboy]

A new update has been posted and it has corrected the issue with wall mips such as the ones at Mid Ohio:
https://www.vogons.org/viewtopic.php?p=1266084#p1266084

The track looks really nice now and Ive discovered a couple other tracks like Meadowlands and Cleveland work as well:


I have asked Sharagand about the memory issues and whether or not there is a potential to increase the memory so we may load some of the heavier addon tracks. Outside of the Carset and the tracks issue the sim works really well in Rendition now and looks incredible in High Res. I really hope we can find a way to load the other tracks because this could easily be my preferred way to play in the future!

EDIT: Also i believe it might specifically be 4mb of texture files collectively between the cars and track that is the limit. The other data I think is still loaded into conventional memory.