[ARCHIVE] SimAntics & World Development
- Thread starter Rhys
- Start date
- Status
What about grass rendering? If for now you leave out the blades that stick up over the tiles, and you skip the green/yellow coloring, it seems pretty doable at this point.Those aren't important for object function. Plus the wall rendering will be mega complicated and confusing.
Although I have to say I've gotten used to the map view texture we're using now. I think it's even prettier.
Last edited:
That won't provide much of a functional benefit either (that'll provide less!) but yeah, that would be doable. Looks like I just need to generate a perlin noise 2d map the size of the lot, interpolate between the green and brown terrain colours and draw the blades. The only problem would be that there would be 1200 of these blades, and their position has to remain the same as long as that section was onscreen.
Walls use an interesting system that involves an awful lot of masks... They'll need really special shaders to get working (and a lot of loading different assets!).
Walls use an interesting system that involves an awful lot of masks... They'll need really special shaders to get working (and a lot of loading different assets!).
aidancheddar
Active Member
Well, considering this was before TSOR, which lead to PD and NioTSO, it's understandable.
Grass rendering WIP:
Right now it's ridiculously intensive though... It generates 1200*64*64 blades (like the original! not even kidding!) and draws them all when it does the terrain render. To make this less crazy I need to find some easy way to draw lines using the gpu so that I'm not feeding 4x the data and I need to simplify the colour interpolation for blades - probably remove it completely.
Right now it's ridiculously intensive though... It generates 1200*64*64 blades (like the original! not even kidding!) and draws them all when it does the terrain render. To make this less crazy I need to find some easy way to draw lines using the gpu so that I'm not feeding 4x the data and I need to simplify the colour interpolation for blades - probably remove it completely.
Afr0
Well-Known Member
I'm still bugged out by this. Why the hell does everything have to be done on the GPU when the original didn't do it that way?
It seems so stupid to me to intentionally raise the minimum reqs to make the game "faster".
Because CPU rendering is incredibly bad practice and generally the worst idea ever unless you're working really low level, i.e. not with c#.
It may be a better idea to draw grass with a pixel shader and a random seed. We wouldn't be able to make the grass stick out though, and since pixel shaders calculate each pixel individually determining if we're on a higher pixel of a grass blade will be annoying. Right now the best approach seems to be to draw the terrain once and then discard all of the grass blade data to free up all that memory. Only problem is that it still manages to bump up memory usage to like 700MB when generating the grass data, so it's still completely ridiculous.
The pixel shader one would also mess up if the terrain were drawn at any half-steps... Why did they have to draw terrain like this??
It may be a better idea to draw grass with a pixel shader and a random seed. We wouldn't be able to make the grass stick out though, and since pixel shaders calculate each pixel individually determining if we're on a higher pixel of a grass blade will be annoying. Right now the best approach seems to be to draw the terrain once and then discard all of the grass blade data to free up all that memory. Only problem is that it still manages to bump up memory usage to like 700MB when generating the grass data, so it's still completely ridiculous.
The pixel shader one would also mess up if the terrain were drawn at any half-steps... Why did they have to draw terrain like this??
Last edited:
xezno
Member
I don't know. Maybe to impress everyone xP
francot514
Well-Known Member
Impressive image, i want to ask there is a problem if you add residential objects like beds to this lots...
Residential objects can easily be manually added without problems. Remember that all beds are multitile though - the version you have doesn't yet have support for that (and the pie menu checks crash anyways lol)
I'm going to implement walls next as I've mostly figured them out. The only challenge will be changing the cutout when certain objects are on the wall, which I'm not sure how to do atm (as in where do i find the information on the new cutout and if one is needed, what wall to apply to etc).
I'm going to implement walls next as I've mostly figured them out. The only challenge will be changing the cutout when certain objects are on the wall, which I'm not sure how to do atm (as in where do i find the information on the new cutout and if one is needed, what wall to apply to etc).
WIP walls. The walls that are found in external iffs have their ids correct, but the ones in the global are hilariously wrong:
Loving that classy pink wallpaper. It doesn't yet have z buffers, cut outs or the thickness graphics on top of the walls.
If anyone can find the z buffer graphics for the walls (it's probably one sprite, looks like an object z buffer except for a wall and its top) please tell me! I'm still looking for it, and it really has to exist...
Loving that classy pink wallpaper. It doesn't yet have z buffers, cut outs or the thickness graphics on top of the walls.
If anyone can find the z buffer graphics for the walls (it's probably one sprite, looks like an object z buffer except for a wall and its top) please tell me! I'm still looking for it, and it really has to exist...
Right, I gathered all of the iff files in objiff.iff and the globals folder, ran iff2html, and looked at all the images that ended in "_z" and also all the images in walls.iff, global.iff, behavior.iff, and sprites.iff, and I also looked at lightmap.dat again, and I didn't find any z-buffers for walls. Generating your own z buffer definitely works since all doors are flat, so it's not a huge issue.
I'll have to generate a z buffer for the wall thickness junctions too, but it should be easy enough. The walls down junctions use a trick where they don't have the z buffer you would expect - they actually use the same z as the wall under them, so that the junction doesn't go through objects on the direct other side of the wall (the walls in ts1 are not actually physically possible, they're a pretty smart illusion). The walls up junctions do have a flat floor like z buffer though.
Walls cutaway uses an extra overlay wall pattern as well as replacing the wall's style with an alternate mask, but it also has the special effect of removing that wall from the junction graphic as the overlay handles its own thickness.
Walls cutaway uses an extra overlay wall pattern as well as replacing the wall's style with an alternate mask, but it also has the special effect of removing that wall from the junction graphic as the overlay handles its own thickness.
If anyone has an irrational fear of flags, look away now!
This is the Dictionary I need to use for looking up the correct junction graphic to use. Thankfully because of this massive wall of text, the implementation will be really easy as I'll just need to construct the junction flags and pass that to this dictionary to get the correct index for the graphic.
This is the Dictionary I need to use for looking up the correct junction graphic to use. Thankfully because of this massive wall of text, the implementation will be really easy as I'll just need to construct the junction flags and pass that to this dictionary to get the correct index for the graphic.
- Status