Pushing DOS GCS to its limits

[Mystery]

aka. trying to figure out just how much one can do with the engine.

The smallest texture/object I was able to put into the game had a h-size of "40" units. Anything below that gets scaled back up to the usual 400 units.

I also experimented with texture size.
64x64 is the standard, anything below that looks really shoddy for a standard size wall.
128x128 seems to be the best option, if memory permits, as it gives a high quality look with reasonable memory requirements.
256x256 doesn't seem to be possible with GCSEdit, so I used 200x200 instead. The improvement in quality is only visible when being really close to the texture but I don't think it's worth the huge memory usage. Maybe for some rare detail textures.

One thing I noticed was a lot of flickering pixels due to a lack of mip mapping when moving further away from hires textures.



Right now I'm interested in two things

1) Figuring out the amount of detail the engine can display in a small space. Theres obviously a limit to the number of objects etc. in a level, but I'm not sure if there will be any glitches when there are a lot of small objects cramped together. I remember even the original DOOM engine had its issues at certain spots in the game until it was patched.

2) Trying to reduce memory usage as much as possible, while still displaying as much detail as possible.
What methods could be used here?
Splitting up areas into several smaller levels might work to a certain extent.
Also, to reduce the memory used by textures I'm trying to to figure out the best way to fake decals/sprites onto walls.
Instead of using a second wall texture which just has some cracks, grafitti or a sign on it, I'm putting a lowres transparent wall in front of it.
Especially when using 128x128 textures, that could potentially save a lot of memory and allow for more details in levels without sacrificing too much memory for loads of almost identical hires textures.

However, there seems to be a problem when viewing these from a certain sharp angle, resulting in the transparent texture to disappear. Putting it further away from the "real" wall helps, but then it appears to be "floating" in front of the wall when strafing in front of it.


I posted this image in another thread already, but here it is again:

The grey textures in the background are 32, 64, 128 and 200 pixels wide.
The wood columns in the front are the unit width test blocks. The one on the left is 40 units wide. It's not possible to make anything smaller than that in the GCS engine.


Any additional tricks or tips are gratly appreciated.

[Mystery]

Here's the different texture resolutions in comparison with a default 64x64 texture:
32x32:
1.22KB texture

64x64:
2.43KB texture

128x128:
7.85KB texture

200x200 (moving closer to the wall to see a difference):
18.1KB texture


As you can see, the loss of detail is already pretty extreme in the 64x64 texture.
The 128x128 texture looks very nice. However the improvement by using the 200x200 texture is almost negligible despite using more than two times the memory.

Sure, 128x128 textures habe a pretty large filesize compared to the 64x64 ones, but it's still manageable (I think).

[Saturdaynight]

Great write up!

A few things:

The DOS engine level editor is capable of displaying 200 object in a level at one time if memory servers me correct. The windows engine with the lite windows level editor is capable of 700 objects and with the full windows level editor you can have up to 2000 objects.

One things I've run into is using windows walls with objext that have too many whole, causes the engine to crash when loading the game. So, for example, when making a chain link fence, you should be careful how many links you create. The engine has trouble with writing data to show images in the background when too many wholes are in your foreground objects.

Note: The fewer wholes in object that you have, the less likely you are to have draw in effects.

Another way to reduce CPU usage is to select "Don't Draw Backsides" in the Attributes dialog box. This cuts down on how many images the engine has to draw into the game level.

Interesting how you use the transparency to have an image ontop of another image. Have you thought of using Photoshop or Gimp to add layers to an object then save it as a bitmap and import it into the engine? Perhaps I'm missing the point on this.

Great little demostration of imaging. Most people may forget that floor textures, in the DOS level editor are limited to 64x64 textures. Generally, if you use anything larger, it will tell you this. Transversely, wall textures are not limited to that resolution.

Again, nice little write up!

[Mystery]

Alright, about the transparency thing:

Imagine you've got a large texture in your game for a wall tile, like 128x128 pixels.
Now your level design calls for a slightly modified version of that wall texture. Let's say it needs a poster, a sign or whatever.

Now usually you'd just take the original texture and paint the required image on top of that, save it and import it in the GCS, right?
But if you add a lot of detail to your levels wall textures and use 128x128 textures, you'd quickly run out of memory and are forced to reduce additional details or the texture resolution.

What I do is create a transparent version of the thing I want to have on the wall in the same or a slightly lower resolution (depending on the level of detail I need) and put it right in front of the wall.

Now I still have the high resolution wall, but with a "fake" sprite in front of it. But instead of using another 16KB it just uses 4KB and is more flexible because I can put it anywhere I want instead of making a different new wall texture for every appearance of the object.

If the detail texture gets used a lot on different surfaces and if memory permits, I could also make a hires version and still save a lot of memory.

Allow me to demonstrate:

This is a wall texture with a transparent texture right in front of it, but it looks like it's one texture.


This is how it looks in GCS


This is how it looks up close


However, there is one drawback which I have to figure out: At certain angles, the transparent texture disappears, like this:


This method isn't always the best solution.
If you have a hires wall which needs a hires detail that's not going to be used anywhere else in the game, you'd just make a new wall (like you suggested in Gimp with a second layer).
However, if I wanted to use that detail texture on top of many different wall textures, I'd quickly get into trouble because I'd have to create multiple new textures which would eat up memory like crazy.
In addition to that, if the detail doesn't need to be as high-res as the original texture, I'll save memory as well with this method.


I hope this explains my approach.
In more modern raycasting engines like the Build engine (Duke3d, Shadow Warrior, Blood) it's easy to plaster sprites on walls like there's no tomorrow. Even DOOM is more flexible because you can put in tons of textures without worrying about memory.

In my example I could use the "test" sign in front of a stone wall, a brick wall, a wooden block and several other textures and it would just require 4KB in total. While I'd have to make half a dozen new textures with the traditional approach, using up 20KB or more in the process.

[Saturdaynight]

I get what your saying now.

[Mystery]

I don't have a whole lot of time these days, but right now I'm trying to get a tiny little bit of GCS development on the weekend

I've only done a small test this evening, but it was quite interesting and relevant to my goals with this engine.

To create scenes with very high detail, the engine needs to be able to display a lot of detail at once, so I build a small testing scene with a lot of walls being in the players field of view at once to see if there are any graphical anomalies.

Here's a quick screenshot:

That should be more than 100 wall objects being displayed at once.

As you can see, the engine performs quite admirably. I've used alternating textures to better visualize the amount of walls in sight. There are no graphical glitches or other errors while moving through or turning in this corridor. I didn't expect that.

I think the engine is quite good at displaying a high amount of detail in a small enclosed space, so the 320x200 resolution is mainly the limiting factor when it comes to fine detail, especially when the player is at a greater distance.


But the texture resolution test and this one prove that it should be possible to create very detailed small scenes, like single rooms, with high resolution textures and a lot of detail.

I think the editor might be the biggest hurdle in creating such scenes, because it doesn't really work well at high zoom levels and many small objects at high density. But we'll see

[lgb3d]

Do I need to have images uploaded at a different location and use HTML in the text to post it here?