Not logged in, Join Here! or Log In Below:  
News Articles Search    

Submitted by [MoW]-=Comanche=-, posted on February 01, 2001

Image Description, by [MoW]-=Comanche=-

This screenshot was taken from my new Voxel based 2.5D Voxel Engine (I call it 2.5D because it's not truly 3D). The Rendering Algorithm is coded in Assembler, so I get a very good scrolling speed on my Athlon 500. The Landscape is Gourand shaded and 32-bit.

I'm only 16 years old so this is my first try in programming such a huge thing. I hope you'll like it.

Do somebody have a idea how to render transparent liquids in that trench? All my Alpha-Blending stuff is very slow.

If you like it please give me feedback to:

Image of the Day Gallery


Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
Graham Gibbons

February 01, 2001, 03:36 PM

How about a download?


February 01, 2001, 04:29 PM

Wow, looks great !!!

What about the resolution ? 640x480 ?
What do you want to do with this 2.5D engine in the future ?


February 01, 2001, 04:30 PM

Looks like the making of a good strategy game. Why voxels instead of 2D tiles though?

Matthew Morrow

February 01, 2001, 05:03 PM

Cool, reminds me of scapex.


February 01, 2001, 05:29 PM

Looks very nice!

How much time you spent coding it???

which systems you have already done???

how the render pipeline looks like??

keep on coding!


February 01, 2001, 05:36 PM

>> Do somebody have a idea how to render
>> transparent liquids in that trench?
>> All my Alpha-Blending stuff is very slow.

DISCLAIMER: I'm a lamer. I've never actually done this (quick, software blending), but I was thinking about it recently. Let me know if you think it'd work.

If the colors are represented as 0x00RRGGBB, then the following should be a quick way to average two colors:

int color1 = 0x00ffffff;
int color2 = 0x00007f00;

#define MASK 0x00FEFEFE
int color_ave = ((color1 & MASK) + (color2 & MASK)) >> 1;

How it works: (or how I think it should work) 8-)

To average two colors, you want to average the red, the green, and the blue seperately.

int color1 = 0x00ffffff;
int color2 = 0x00007f00;

int red = (color1 & 0x00ff0000) >> 16;
red += (color2 & 0x00ff0000) >> 16;
red /= 2;

int green = (color1 & 0x0000ff00) >> 8;
green += (color2 & 0x0000ff00) >> 8;
green /= 2;

int blue = color1 & 0x000000ff;
blue += color2 & 0x000000ff;
blue /= 2;

int color_ave = (red << 16) + (green << 8) + blue;

By killing the least significant bit (and-ing with the MASK), you can safely add all three components of the ints (r,g,b) together at the same time without worrying about overflow. Since the largest value for any component would be 255, you'll never see an overflow larger than a bit. (0xff + 0xff = 0x1fe).


You lose precision. When you and with the mask, you lose the least signifigant bit. So a red of 255 becomes 254. Not a huge deal.
This is even blending (50/50). Although variations on this theme could produce 66%, 75%, ... by weighing the average of one number. (ie. (c1 + c1 + c1 + c2) >> 2). Of course, you'd have to monkey with the mask, and you'd lose more precision.
Since you're doing the voxel thing, you can't render a voxel over a voxel -- that is, the rocks can't "show thru" the water like they would in 3d. You'll need to pick a new hight above selected rock voxels and color it with this average. Using an animated hight-map and texture map for the river, I think this would be a pretty cool approximation - but the only way it'd be accurate is if you selected your texels from the rock texture and the river texture based on a line cast from the viewpoint. So if you're looking from directly overhead, the rock and river textures align perfectly -- if you're looking from any other angle, you'll need to select a different rock texel based on a cast ray.


February 01, 2001, 05:59 PM

that is a very cool idea groundhog, i have reviewed your logic and it does work. losing the least sig bit, so a 255 does become a 254, this is a big deal. because ANY odd number will become a lesser even number (since the 1 bit is gone). so this reduces your precision by 50%, which may or may not be a big deal. i think this would introduce too much visual anomolies if implemented. is this how any one else sees it?


February 01, 2001, 06:05 PM

That is a very common method for 50% transperency. You can be even more accurate by doing this:

color = ((color & 0xfefefefe)>>1) + ((backColor & 0xfefefefe)>>1) + ((color|backColor) & 0x01010101);

S°ren Hannibal

February 01, 2001, 06:25 PM

About losing precision:
I have used the remove-least-bit-add-and-shift in a game before, and I would say that the impact of losing the least significant bit was minimal. It was mainly used for explosions, and was therefore very quick, but you never noticed any loss of detail, even though it only used 15-bit colors (it was back in the old days before 24-bits, let alone hardware rendering). Remember that when you blend the colors the image becomes more chaotic, and it is harder for the viewer to focus on the details.


February 01, 2001, 06:49 PM

Sorry if my math's wrong, but...

If you kill the most signifigant bit, that a precision loss of 50%, but killing the least signifigant bit, it's more like a 0.4% loss.

Navreet Gill

February 01, 2001, 06:50 PM

Yeah! Teen programmers! (I am in highschool too ;)... Wohnen sie im Deutschland?


February 01, 2001, 09:07 PM

Es hei▀t IN Deutschland, macht aber nix :-)

Jason Kozak

February 01, 2001, 09:56 PM

Wow, I wish I'd done something like that when I was 16. Very nice work.


February 01, 2001, 10:06 PM

>> Wow, I wish I'd done something like that when I was 16. Very nice
>> work.

I'd imagine you would have - if you'd had an Athlon 500 instead of a 386 ;)


February 02, 2001, 12:50 AM

How did you do such smooth trasitions from one tile to the next type? Its something i am trying to figure out in my 3D terrain engine where each tile is a clear cut from the next.


The Wolf

February 02, 2001, 01:01 AM

Very good, keep up the good work.
Next step a full 3D landscape engine for that nice editor of yours :)


February 02, 2001, 01:17 AM

Very nice work. Thank god it's not another 'landscape engine'. God that annoyed me when everybody had to post their landscape engines on IOTD. It looks nice, a demo would be nicer tho.


February 02, 2001, 02:53 AM

Oooh I like this idea. I use 50% blending myself, Thanks. There would be no precision loss at all right? Not that I'm worried. I used code like the original poster previously. Since I don't need the alpha channel though I'll remove 1 shift, thus:

color = ((color & 0x00fefefe) + (backColor & 0x00fefefe))>>1 + ((color|backColor) & 0x00010101);


February 02, 2001, 02:59 AM

A 2.5d landscape and name like Commanche? Why does that bring up such... Olde sk00l gaming memories? :)Very cool looking pics and well done looking interface :)

Anyway, as has been pointed out by many people before, you aren't supposed to call these style of engines "voxel" any more. Maybe a name like height sampled vertical splats :)


February 02, 2001, 04:46 AM

Two things about your piece of code.

1. Replace the lines

red /= 2;
green /= 2;
blue /= 2;


red >>= 1;
green >>= 1;
blue >>= 1;

because shifiting is faster than dividing. It might be you won't get any speed advantage because the compiler itself replaces you division with shifting.

2. Your using the typical 32 bits color notation (0x00rrggbb). As I know, some cards have different rgb formats and so your code might not work on every card. But I must say, eery card I ever used was 0x00rrggbb format.

Good luck with it!


February 02, 2001, 05:45 AM

color = ((color & 0x00fefefe) + (backColor & 0x00fefefe))>>1 + ((color|backColor) & 0x00010101);

will not work, but color = ((color & 0x00fefefe) + (backColor & 0x00fefefe)>>1) + ((color|backColor) & 0x00010101);

This is because of the order of precedence.


February 02, 2001, 05:57 AM

Thats fucked up, either way you lose one bit of precision, 8bits become 7bits by masking out any of the bits, so its a 50% loss both ways.

You would never want to mask out the most significant bit because it shows, you lose 50% of the intensity and it would be dark as hell, but the least significant bit only loses 0.4% intensity and you wouldn't notice.


February 02, 2001, 06:48 AM

Hm. Mostly, games developers use 16-bit texture formats which therefore have only 6,5 or even just 4 bits of colour per gun. Retaining 7 bits per gun seems fine to me.

Of course, I play Quake 3 with 32-bit textures enabled, because it looks much better.


February 02, 2001, 07:36 AM

Yes, good point, 7bits per color is still much better than normal 16bit colors.


February 02, 2001, 08:12 AM

that's what i'd like to know... i think you can do it with alpha blending masks but then how would you do it in a voxel engine?


February 02, 2001, 09:05 AM

About creating transparent liquid...couldn't you use multitexturing?


February 02, 2001, 09:21 AM

I want to answer some of your questions:

1. Yes I will post a d/l. Please be patient...
2. 2D Tiles are to easy. I wanted to do something special *g*
3. I have NO time for the engine at the moment, because I'm very bad in French and Spain in school :(
4. Uhm how much time did I spend... 2 Years ?!? First I had to learn C++ then DirectX. This is my first system, guys I'm 16.
5. About the rendering pipeline: Do somebody want to give me some Web Space for some informations about the engine and perhabs source-code?
6. I will try that when I have some time. But C++ is to slow. I'll do it in Assembler.
7. I'm German, that's right!
8. Multitexturing? Hey this is NOT 3D-Accelerated!

I could write some tutorial if flipcode would like it...

Mathieu 'PO¤' HENRI

February 02, 2001, 09:47 AM

why do you separate red,green and blue??
you simply have to separate magenta and green to do correct 32bits alpha blending

and if you accept to loose the LSB of every single composant, saturated add/sub can be performed without even separating them (in non-mmx code)

obviously mmx code is really good for color blendings and is quite easy to learn


February 02, 2001, 09:47 AM

Ehm one further thing to add:
I can deform the landscape in realtime. So you could let crash asteroids or something like that.

Saad Faisal

February 02, 2001, 09:52 AM

>I could write some tutorial if flipcode would like it...
I think that should be your first step and as far as your age is concerned, while i was browsing a review on Graphics Gem i read a review of a so called 12 year old boy so i think you are not that BAD.

Keep up the good work and BTW not everybody on this list is native American. I am Pakistani BTW.

This thread contains 55 messages.
First Previous ( To view more messages, select a page: 0 1 ... out of 1) Next Last
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.