Support for Alpha channel graphics

[Gambit37]

I know you are already using translucency and alpha channel effects for the shading and light diminishing, amongst others.

Does this mean that it would be easy to build in support for a format that stores an alpha channel, such as PNG or TIFF? This would allow some cool effects on items and monsters, and they could have anti-aliased edges which would blend nicely into the background. Objects could also have soft shadows when they are on the ground, the Window spell could be more subtle, etc etc.... (drool....)

It would also be cool to specify the transparency level of ANY individual graphic - not just those you have chosen yourself - so that we could make semi transparent wall items for example.

[George Gilbert]

No it wouldn't be possible to implement PNG/TIFF style transparency for parts of objects. This is solely for speed reasons. Working out which bits are and which bits aren't and faffing through the code slows it down massivley; it's slow enough at the moment with a single bit (either it's transparent or it's not).

Also the degree of transparency isn't configurable (either it's 50% transparent or it's not at all) again for speed reasons (it's quick to divide the colour values by 2 and add them to the background div by 2; for arbitary values it'd be dead slow).

However (phew), *which* graphics are transparent is entirely configuarble so you can change that as much as you like!

[Gambit37]

Shame about no alpha channel support, but I can understand you reasons for not including it. Speed of play is far more important than realism at the end of the day.

[George Gilbert]

That's essentially the size of it. RTC has trouble running on a 200MHz system as it is. Once the frame rate drops below about 20fps the mouse support gets very jerky. Changing graphics to complex forms will really kill it off!

[Gambit37]

I have to ask then, what makes the original DM so efficient? It runs on a 14Mhz Amiga perfectly well, and an old 8Mhz(?) 286 PC.

I know that you're using DirectX, but I thought the whole point of DirectX was to make games run quicker and more efficiently. It seems strange that a simple game like RTC has problems with frame rate when Half Life runs on my 233Mhz Pentium class PC in software only mode, at a (just) playable rate.

[George Gilbert]

Difficult to say. It's largely based on the amount of blitting it has to do to the screen.

The original DM used small 4bit graphics but RTC's graphics are 4 times larger (it runs in 640x400 rather than 320x200) and in 24bpp. That's an extra factor of 24 times slower in the blitting routines (which make up nearly 90% of the time it takes for each frame). Additionally the smooth lighting effect is done by alpha blending a black layer over the entire surface (slowing the frame rate massively) rather than palette shifting (virtually instant). In all from graphics alone RTC will always be running some 30-40 times slower (i.e. the difference between running well at 8 and badly at 200 MHz) than DM ever did, and that's before you start factoring in the in-efficiency of my coding

George

[Gambit37]

Wow... I guess I've never worked out the maths on this before! Of course, you're right. I simply didn't realise what kind of factors were involved in getting 24bit graphics onto the screen.

I'm sure your code is very efficient George; let's just blame everything on Microsoft

[Gambit37]

Just resurrecting this very old post as I have some more questions about Alpha Channel support.

For the last few days I've been thinking about replacement graphics for RTC and have come up with literally hundreds of really cool ideas. I'm very keen to develop this over time into a custom scenario for RTC.

However, so many of my ideas really do require some form of alpha transparency. I humbly ask if it would be possible to add this support? I'd love to be able to take a PNG and drop it straight into the engine and have it "just work"! . I do understand the performance issues, but that's becoming less of an issue with modern machines, and it's not as if any items that use Alpha transparency would end up in the dungeons bundled with RTC. It would however be a cool option for custom dungeon builders...

I also ask because I want to start developing graphics fairly soon, and if Alpha support might one day be added to RTC, I'll wait for it: the way I develop my graphics is largely dependent on whether or not Alpha channels will be supported in RTC.

Fingers crossed!

[cowsmanaut]

I'll have to pop in here and add my support as you knew I would.

Personally I think it would be a nice little challenge to get the speed up with alphachannel support. I only say this because I know it can be done. I've seen it. A number of fully animated characters and background objects all runing around with alphachannels with sound and the whole thing in a java engine. Now Java is way slower than direct code. So you should be able to do the same thing faster. This was running proper speed on a 260mhz MMX machine by the way.

take it as a challenge and set up a flag at the start of a dungeon that turns on or of alpha support. Then leave a warning about buyer beware. Turn it on and it will slow you down.

Try it for us... please please please please please please please!!

moo

(edit: also there is the possibility of using 16bit images with 4 bit grey scale masks. if that might be faster?)

[Tom Hatfield]

Adam thought it would be a good idea if I popped in here and tried to help George put alpha-blending into the engine. Let me tell you, it's a joke doing something that simple, but only if you utilize Direct3D as your renderer. If you do that, you can load alpha-interpolated (or -separated) images without any extra code, and the hardware does blending for free (when it's available. . . and on every modern system, it is available).

Okay, I understand your engine does not use graphics that are powers of two in size. I also understand Adam is in the process of redoing the graphics set, so he has a great opportunity to reformat them to match the power-of-two constraint placed on nearly every consumer video card. (I recommend either 512x512 or 512x256, unless you expect RTC to run on a lot of old cards, in which case you'll need to split them into 256x256 chunks.) So, if you wanted to modify the engine to use hardware alpha-blending --- and hardware rendering for that matter --- then now is exactly the right time to do it.

Interested parties (namely George, but anyone is welcome) may contact me at deathnegro@earthlink.net for details, but I'll give you a basic idea of how you'd go about implementing a 3D-accelerated renderer that supports direct loading of 32-bit image formats.

The first step is to use DirectX 8, because you can't get the effect without tremendous hassle in any earlier version. Because there is no DirectDraw in DX8, you no longer have to worry about DirectDraw; thus, you may move immediately into Direct3D, which is no more difficult to use if you only want to render 2D graphics.

You'll be making use of Direct3D, numerous texture surfaces (for which you will probably want to create a texture management class. . . I have created such a class, and you're welcome to take a look at it), and lots of vertices. Graphics artists must copy the DDS file format plug-in to their Photoshop directories. (I'm uncertain as to whether the plug-in works with PSP7, but it couldn't hurt to try.) The plug-in used to be available at NVidia's developer site, but I gave Adam a copy so maybe he'll put it here for download.

You'll also be using a D3DX (Direct3D Extensions) object to load your textures, because it supports loading of DDS files. When you have the D3D renderer and texture manager in place. . . well, everything else will work itself out. The renderer can be completely encapsulated (as mine is) so you needn't worry about compatibility with the engine's older components.

I'm willing to help in every way, even going so far as writing the new engine myself if it comes to that (though I'd much rather not, as I'm busy now with school and my own projects). Give me a jingle and we'll get started right away.

[Gambit37]

I believe the hardware dependency is one issue that George would like to avoid. Is it possible to achieve this effect in software only? How do games like Half Life work when they use their own software renderer?

Also, I'm not sure how much of this is a consideration, but you only get DX3 on NT4 and earlier, so it would mean that RTC would no longer work on that OS. I thought Alpha Channel support was a basic component of even the earliest Direct X?

To be certain that we're singing the same tune: I don't think RTC requires a full alpha channel hardware renderer; the 'nice to have' that Cow and I keep banging on about is simply to be able to load images with an alpha channel so that we can use transparency and have anti-aliased edges. Can that not be achieve more simply than with your proposal for a full engine? DMJava can load PNGs directly and use the Alpha information; that's the kind of support I'm looking for...

I just took a look at the Nvidia site, and the DDS plugin for Photoshop now requires DirectX9!

Finally, it's worth remembering that George undertook RTC as a way of learning games programming, from scratch. I believe that he would prefer to keep the engine as free from reliance on external APIs as possible, so that the core code will always be his. I am certain (but willing to be proved wrong) that Alpha support can be implemented in some way without such a reliance on DirectX.

This was a quick brain dump early Sunday morning, so if any of it doesn't make sense, or I'm making wild assumptions, well, please correct me!

[cowsmanaut]

yes, back in the beginning, I was the bone head who kept whining about NT support. However, it seemed I was the only one at the time. The only reason I was using it was software that only ran on NT based OS and 2k wasn't ready yet (still too buggy) However, I made the jump many a year ago so I wonder.. are there any NT people left out there?

I'm well certain that it can be done with GFX sets of TGA or PNG as well. Also image sizes that are not a direct factor of two. The only point I *think* he was trying to make was that there would be a big speed gain from doing it all this way. Direct X format will be translated faster than annother, using computer friendly numbers when making your graphics will let the computer again digest them easier.

anyway, this is one of many suggestions. I'll hunt around some more.

moo

[cowsmanaut]

back with some info. I rifled through some tutorials and looked to see if there was anything usefull in them that could be ported to RTC. There was one nice one on binary space partitioning trees, however, I figured you might have already learned plenty about BSP trees already. For all I know you already use it for your hidden surface removal. Since I imagine you are doing it in software rather than using the hardware options available on 3d compliant cards.

anyway, here they are..


Sorting and alphablending
http://www.gamedev.net/reference/articl ... le1594.asp
http://www.gamedev.net/reference/articl ... cle320.asp
http://epaperpress.com/sortsearch/
http://www.gamedev.net/reference/list.a ... ryid=25#27

fast lighting?
http://www.gamedev.net/reference/articl ... cle998.asp

fast graphics blitting that is bit depth independant.
http://www.gamedev.net/reference/articl ... cle538.asp


moo

[Gambit37]

That second article was interesting; it strikes me that the additive blending would be perfect for stuff like Fireball explosions and the like--it would stop them looking muddy and washed out.

[Tom Hatfield]

Okay, we need to shoot down all these false assumptions before anyone dissuades George from implementing the alpha-blending you guys are asking for insistently.

Alpha-blending is not hardware-dependent, but gamma correction is, so it is wholly impractical to use gamma correction for localized lighting unless it's software driven --- which stands out as a hideous contradiction when you're complaining about hardware reliance. I understand that I may be the only person at this forum who has experience in graphics programming, which is why I offered to help in the first place. It also means I'll need to explain a lot of things.

I was not aware until a few moments ago that George wrote RTC as a learning experience; thus, it would be extremely difficult for me to remember that he has next to zero graphics programming experience. So, this changes everything, and it looks like I may have a pretty big hand in the engine's new design, if there is in fact a new design.

I don't know where Gambit37 found that DDS plug-in, but it's obviously not the one I use. I don't even have DX9 installed because it hasn't been thoroughly tested like DX8, and it's not universally supported by video hardware. And if you're running Windows and do not have DX8 installed, you seriously need to crawl out from under your rock and get on the bandwagon.

Using non-native DX formats (i.e., anything except BMP and DDS) is not practical because there is a tremendous amount of code required for graphics conversion. Even if you use the Windows API for automatic conversion, you still have to copy the uncompressed image to a texture surface (resizing it to powers of two if necessary) before DirectX can use it in rendering. DDS supports every bit-depth you will ever need, in addition to DTX compression and integrated mipmaps --- and if that's not good enough, you can fall back on BMP.

Gambit37: It is quite possible to perform alias reduction without alpha-blending, but it is prohibitively slow. The process is simple: you average the color value of a small region of pixels. Even the simplest technique (say, a 2x1 linear filter) would require 512,000 operations (64,000 reads; 64,000 adds; 64,000 bit-shifts; and 64,000 writes). Of course, you can vastly reduce this count by processing only the edges of sprites, but I don't see the point.

If you're going to add alpha-blending for one reason (alias reduction), you might as well add it for every reason (transparency, translucency, additive blending, subtractive blending, etc.).

As for Windows NT4 having only DX3, I simply don't understand why this is an issue. Windows 2000 comes with DX5, and Windows XP comes with DX8. If your version of DX isn't recent enough, you install a newer one. What's the big deal? If you can download RTC, you can download a new copy of DirectX.

DirectX 8 is not the most practical version to use if you absolutely must use a software renderer because the reference rasterizer is monstrously slow. (It exists for design purposes only and is not meant to be used in distributed applications.) But if you absolutely must use a software renderer, then you probably shouldn't be programming for Windows. Go back to DOS and use a real compiler.

I also understand that George is using ANSI C. Well, DirectX is written on C++, which means the two are fundamentally incompatible. I don't use any variation of C, so in my case it doesn't really matter.

Here's basically what it breaks down to: if you want the engine to be software-only, then you can count me out. I've done enough software rasterization (alpha-blending, image post-processing, bump-mapping, etc.) to know when it's time to get off the Titanic and start using the video card.

[cowsmanaut]

easy big guy. George does have programming experience, it just as Gambit said. He was using this to learn *games programming*. If I remember correctly he's well versed in programming for science apps.

at any rate. If anything is done it's obviously up to George in the end and how much effort he is willing to add to the workload he has already. That's not to say that you shouldn't keep the suggestions and advice comming. Just don't expect anything to be done with them unless he decides he wishes to do it by himself. As he has mentioned in the past he want's to keep it his own project. So any work done it, is for his benefit first and for us second.

cheers.

[Lubor Kolar]

Very interesting comments from Tom, but I have a question: do you think it is smart to bind RTC with DirectX? It would mean RTC could be never ported to other OSes, like Linux. I suggest to use OpenGL or some multiplatform library than MS-proprietary DirectX.
But I agree that using video card acceleration would greatly enhanced RTC performance. Sometimes I am saying to myself, why Quake2 @1024x768 with true 3D graphics and a lot of eyecandies runs faster on my 2GHz + GF4 system than RTC @640x480. Leaving GPU to make hard work will allow to use CPU for better AI, handling more objects etc.

[cowsmanaut]

I think it is already tied into direct X. Just probably not Direct 3D as Tom suggested. I think the main reason Tom is suggesting such things is to make use of cards that have the hardware to do it quickly (most 3d cards with 8 megs or more can probably do a lot of this I think).

anyway, I'm not sure we are convincing George anyway.

[Tom Hatfield]

Well, that makes things simple. I can't provide any help.

[Lubor Kolar]

Yes, RTC is tied to DirectX, but I think not so deep, I assume in creating screens, bltbits and maybe reading BMP files. All of this (maybe except reading BMPs, I am not sure here) could be done with for example SDL library http://www.libsdl.org/index.php. I was using SDL for simple operations and it worked well. And from the SDL demos (availabe at their website) is clear that it is far more powerfull than for doing simple bltbits.

And then we are just a step from having RTC on Linux/MAC

[Gambit37]

As far as I remember, RTC only uses DirectX for playing sounds; everything else is handled by George's own code, including all the blitting, resizing, etc. That way, if it's ported to another OS, only the sound code needs to be changed.

Having read Tom's posts and some articles about DirectX and alpha blending in general, I now have a better understanding of the technology and the work involved. I can understand why George wants to avoid it!

I think you're right Cowsmanaut, we're not doing a very good job of convincing George! George????

[Tom Hatfield]

This means either (a) George is sick of programming RTC and wants to call this version "final," or (b) George is really adamant about sticking to the original DM and has no interest in providing support for improved graphics. Hard to say which since he hasn't voiced his own opinion yet.

So, if you want a more versatile engine, I guess you'll have to look somewhere else. The good news is that I'm planning to build such an engine using my DX8 framework. The bad news is that I'm still in the design phase, which means it's impossible to tell when the engine might be available. I'll let you know if and when it's ready, should you decide you'd like to give it a look-see.

Don't hold your breath.

[George Gilbert]

Hmmm - so much to say; here's just a brief summary!

First off in reply to the above:

a) No - surprisingly ;-)
b) Not really either

There are several things I like about the current format, in particular the way it "just works" on virtually any box rather than requiring people to download extra software so I'm not overly keen on migating the lot to DX V.gazillion when V.3 does quite nicely (and works on my NT box!). Wrapped in with that is I don't really see the need for a higher version as it works quite nicely as it is (but I'm prepared to be shot down in flames on that point!).

Having said that I wouldn't be adverse to having two different downloads, one for DX3 and one for 8 or 9 (or 10, 11...). This would be quite easy to do as I've written the RTC core with a media isolation layer which has a handful of APIs (for example PlayRTCSound(ID), DrawRTCBitmap(ID,x,y) etc etc) so only a tiny fraction of the code would need re-writing to port it to any other given media framework.

I'll add it to my ever increasing pile of things to look at!

[Lubor Kolar]

I will repeat myself. but wouldn't be better and easier to use an existing multi-platform framework like libSDL (I mentioned it above) so you'll avoid creating your own APIs and you could use the all the power of the framework (3D support, HW alpha etc.)

[Tom Hatfield]

It works, but I wouldn't say it works "quite nicely." I think there are a lot of people who agree that it runs painfully slow for such a simple 2D game. Indeed, the control response on my AMD550 is pretty sluggish.

You wouldn't need to release two different versions of the game, George. You could add support for advanced features and turn them on or off depending on whether or not the user's PC supports them. The best way I can think of doing this is to have an interface for your I/O engine. You then create (at least) two separate engine classes that inherit this interface.

Ah, except you're using C aren't you? I've never had to worry about the non-object-oriented nature of C because I use Visual C++. (In other words, I've written C-only programs, but I wasn't concerned with whether or not they had objects in them.) So, I guess inheritance is out, unless you're willing to rewrite parts of your engine.

[cowsmanaut]

I think two different versions sounds reasonable as it would seem you have a stable working version for all PC's now and the advanced one using DirectX/3D would probably work on most PC's again as most people are inclined to get a new vid card before they get a new CPU/Mobo. (well gamers at least) Plus as suggested using direct X 7 or higher would probbly even give you a nice speed boost as well as added features.

Also if you stick to about dx7 or so most people using Linux and Wine will probably be able to run it as well.

I'd forgotten you used NT as well, You also have a win9X box as well don't you? For your NT box.. you may want to jump onto 2K. I was unsure about the jump back when I made it but I had more reason to then. Now we have service pack 3 and the bugger is as stable as can be. All the stuff that was NT specific works well on it and anything I could run because of the way NT was built runs fine now too. I honestly think it's the best OS M$ has ever released. XP can be pretty good as long as you go in beat the crap out of it and tear out all of the goodies, modify the registry and then reboot.

Anyway, thanks George for making an appearance and putting up with our whining, though after two years of Gambit and I whining about this particular topic.. I'd imagine you'd be used to it anyway

moo

[Tom Hatfield]

XP Pro is definitely the way to go if you're a Windows user. As for DX7, you can get reasonable performance with per-pixel operations, as you can use the surface pointer returned when a surface is created to access a surface's raw pixel data. (I did this frequently for operations such as bump-mapping and alpha-blending.)

I still think you should rewrite your engine using C++ and use the interface idea because it will result in less debugging hassles in the long run (you'll be working with one program instead of two, and you won't have to duplicate so much code --- not to mention there's less stuff to distribute on your downloads page, and the increase in the size of your .exe will be negligible).

I've got to do some college stuff now, so I'll be back later.

[Tom Hatfield]

Funny. . . we're not just talking about alpha-blending anymore, but a rewrite of the core engine mechanics. I think that's actually a very good idea, and I'd be willing to help as much as possible (going so far as to teaach George how to use DX properly). I do recommend you stick with DX7 because it gives you more control over surfaces.

You said your engine is modular and that the game code isn't tied directly into the engine code, which is the single most outstanding way to build a program. (It's obvious you have a lot of background in that.) This means you would have no difficulty whatsoever rewriting the engine because you can leave everything else exactly as it is. As I said twice already, using an engine interface allows you to keep the engine you've already got while you test out a new, more advanced engine.

A project is never really finished, you know. You just keep working on it until you find something else to do.

[Lunever]

Since I'm using DX9 (like most people who play games occasionally I think) and really are looking forward to the grafix Cows and Gambit want to create, I'd also like to see DX9 support. I personally don't mind whether you do so in a single or 2 different versions, but I guess that one version might be easier (although my knowledge is not really sufficient to judge that properly).

[Tom Hatfield]

You do understand that DirectX is backwards-compatible, yes? So it doesn't matter if it's made with DX3, 5, 6, 7, or 8 --- it will work with DX9. Switching to DX9 for the sake of using it is impossible in George's case unless he rewrites the engine for it (as I've already recommended, but not for this reason) because DX9 is based on the .net framework, which most people have never even heard of, let alone installed.

.net is Microsoft's next attempt at revolutionizing Windows. I won't explain it here. All you need to know is that it hasn't become standardized yet because it's been public less than a year. Incidentally, neither has DX9 become standardized. (There are less than a half-dozen video cards that support it.) The reason people install it is because (a) they absolutely must have every shiny new piece of software Microsoft releases, (b) they intend to program with it, or (c) they just don't know any better. (At the time of writing, no games on the market require DX9 to run.)

Note: the .net framework is not required to run DX9 by design, because you need to download an extra 23-meg archive to install .net (or you need to have Visual Studio .net installed).

Again, if George does decide to upgrade RTC, I strongly advise against making a second executable to release alongside the first. It just makes for more crap the end-user has to download before he gets it to work. It wouldn't be a bad idea to release an update to the existing version, so people who already have RTC don't have to download the whole package again. The key phrase here is "user-friendly," not "programmer-friendly."