Converting CSBWin graphicengine to a OpenGL 3D engine

[Rasmus]

CSBWin3D
**********************************************************************************************************
Download beta project of CSBWin version 1.0e in full 3D with OpenGL (release date: 111105):
Available in the 'Clones' section of the Shared OneDrive at https://1drv.ms/f/s!AsBu7boYHQokbYK3rjKY0b5_ra8
http://www.rasmus-dev.com/games/CSBWin3Dv0.1f.zip (Broken link)
**********************************************************************************************************
This project is a attemt to expand the CSBWin graphic and features as much as posible.

Fixed:
New version:
- Walls and floors can "leave its bounderies", and with this create a more alive dungeon.
- Dungeon heightmap.
- Drinking out of fountain with hands.
- Mousepressing on walldecorations on the side walls.
- Peeking down floorpits, and up roof pits. Also peeking around corners.
- Weather system (some improments needed)
- Map simular to the map in the amiga version of CSB (some improments needed)
- An editor that are able to handle all the new graphics and features inside the dungeon.
- Animated monsters in 24 bit color.
- All wall/floor/door decorations can animated in 24 bit color.
- Skybox.
- Diffrent wallsets in the dungeon.

Previous fixes:
- Party movement and rotation in 3D.
- Monster movment in 3D.
- Item movement in 3D
- Replaced all dungeon graphics in CSBWin too 24 bit color.

In progress:
- Beeing able to add water or lava levels with a transparancy value of own choice.
- Fixing the action and spell bar so that it can have its own graphic and hopefully beeing able to change the layout.

On hold:
- Beeing able to replace and add quality sounds like a torch burning loop sound.
- Two handed combat.
- Minimap over the screen.
- Replacing the inventory with new layout and more colors. Also beeing able to design it yourself as you would like it to be.
- Replacing the championbar above the viewport with graphics of own choise.
- Every spell has its own graphic with animations.

I will update this post as I progress.
I will also add more features if anyone comes up with something new. If anyone is interested in creating a dungeon of his own with this project, I will gladly follow him and add the features that he wants in CSBWin3D.. (as long as they aren't too weird)
All new features can be enabled/disabled by the dungeon designer if he like or don't like them.

Just so everybody knows, I do this because I love programming and expanding DM..
But sometimes I feel like doing something else, so I do this in my own pace and may dissapeare from the project now and then.
I know that you all at this forum respect that, but I have experience of sometimes feeling that I am promising too much.
Therefore this scentence is more like a lifeline for me if I decide to take a break

(The original post was erased and replaced by this one, just so you don't think Paul answer sounds weird )

[Paul Stevens]

Good luck. I created CSBwin but I never figured
out exactly how the graphics routines worked.
Even the names of the functions are only 'best
guesses' and have slowly evolved as I understood
better what they did. Many are still named after
their absolute location in memory!

Some rather clever person wrote very efficient
assembly code to optimize the bit-plane graphics
handling. Difficult to get my head around it.

Notice that I say 'Created' CSBwin, not 'Wrote'.
I merely translated the Atari code, often
without understanding its inner workings.

[Rasmus]

Ahh ok, thanks for the answer.. I will have to see if I can look into it alittle more.. As I said, I managed to change the pixelcolors at certain locations by modyfying the drawrectangle function to 6 lines of code, but in this function it calls other functions that calls other functions etc. So I am afraid that there is still to much code for to little doing.

The purpose of this is that I want to be able to be able to fill the viewport with my own images at my own scaling in high speed, if I do it right I can't see that this should be any problem. Doom for example can run at a 66 mhz computer without a 3d graphiccard and get a smooth animation at a resolution at 320x200, and the dm viewport is much smaller..

I also want to ask you.. Is it posible to use more than 16 colors? I can imagine that this would be a problem because the memory allocated for the viewport is restricted to a certain size, and adding lets say 256 color would need a memory allocation at atleast the double size, not to talk about true colors, that would need eight times larger array right?

I am wondering.. If I only use the viewport for my own code and not anything from the original code.. Then I could take control of the viewport and draw exactly anything I want without anything else interfearing.. hmmm

What do you say Paul?

[Paul Stevens]

I repeat.....Good luck.

If you want to take control of the viewport, you
should probably take control at the next level.
See WinScreen.cpp. It draws the various parts
of the screen separately. One part is the
viewport. At that point you have 16-bit color
and will interfere with nothing else. Of course
there are times in the game when the viewport
area is being used for something else. The
SAVEGAME dialog is a prime example. But
these things are easy to get around.

I can help you at this point in the code because
I really did 'Write' it.

[Rasmus]

Good to know.. I will sit with it tonight and see what I can do..
It is a good thing to know that WinScreen.cpp is the one that output the viewport to the screen.. Maybe I can skip that part and let it output another 32 bit bmp at the same location instead..

If I load a bmp file in the traditional way, and be able to output it instead of the viewport on the screen.. Then I can use the same bmpfile as a backbuffer to the viewport, and I will be in business

[Bit]

Have tested it just in my source - but - comparing my source and csbwin, the moment the viewport gets blitted to the main screen should be this line:
Instrumentation(icntCopyViewportToScreen);
just search for it in the file csbcode.cpp - routine vblInterrupt.
If you replace something here, you shouldn't have problems with the mousecursor, still - as Paul says - you have to care for the 'wake up' screen. Compile CSBwin commenting that line and you'll see the effects.

[Rasmus]

This is how long I have come so far.. It is extreamly interesting programming at so low level compered to direct3d and simular..


As you all can see I have managed to take over the viewport and draw in almost true colors.. At first I created by own bitmap and replaced it where the the viewport is usually draw in WinScreen.cpp (thanks Paul ).
But then I noticed pauls "BITMAPINFO bitmapInfo;" that was the "backbuffer" to the screen and used that one insted (I also noticed that it used R5G5B5, that was alittle bit annoying because it took me some time figuring out why the usual r8g8b8 didn't work, but it is still okey, just wanted to get rid of the palette).. The arrow is drawn over the viewport as shown in the picture, but I am having some problem with the palette still. What I am doing now is that I clear the viewport with a specific palette index, and all other colors that are drawn opon it afterwards (like the arrow) is not replaced by my new viewport. But because I only have 16 colors to choose from it becomes a problem, don't really know why, but sometimes the color I choose gets changed, and even if I change it back before it gets drawn it still doesn't work.. Alittle bit confusing to explain but I think I will figure it out later..
Btw. as shown in the picute you all can probably see that I choosed black color as background, therefore has the black arrowborders dissapered.

I also have a question to you Paul. Why do you have such a large bitmap for backbuffer? (i16 bitmap[320*4*200*4])
I understand that when the window gets scaled x4 the the bitmap is filled, but why didn't you have i16 bitmap[320*4*200*1] instead and then resized the bitmap over the screen? When drawing to the bitmap with a scale x4 it needs to draw 16 times more pixels than when it isn't scaled..

The speed of my drawing is slow, I can fill the whole viewport at 1-2 ms. But I need to be able to fill it alot faster As it is now I use "for" loops, I know that I can speed it up alittle by modifying some things, but I am more interested in BLT1 functions you have created:

Code: Select all

void BLT1(unsigned char *src, 
          i16 *dst, 
          i32 num, 
          i16 *palette,
          ui8 *overlay)
{
  _asm
  {
    mov esi,src
    mov edi,dst
    mov ecx,num
    mov edx,overlay
    mov ebp,palette
    sub ebx,ebx
next:
    movzx bx,[edx] //overlay byte
    inc edx
    shl bx,4
    or  bl,[esi]   //Graphic nibble
    inc esi
    mov ax,[ebp+ebx*2]
    mov [edi],ax   //to screen bitmap
    add edi,2
    loop next
  };
}

If Paul, Bit or Sophia could explain these alittle for me so that I can modify them for my own code I would appricite it alot This would be a goldmine for me because I know that I need to speed things up here and there in DMT too..

@bit: I looked at the routine vblInterrupt, it seems to have something to do with the cursor, viewport and probably something more, I can take a deeper look at it tomorrow, but now I am very tierd.. It would be a speedincrease if I were able to draw the pointer and more over the viewport instead of sneaking the viewport under it.. But I will probably take a look and see if I can get the amiga-viewport-items-in-color now when I have gotten rid of the palette instead

Now I will go to bed.. But I must say that the way CSBWin handles the graphic is very interesting and I can't wait to get back to work, thanks for releasing the sourcecode to us Paul

[Bit]

Those exx are the 32 bit-registers of the processor. Of course direct assembler-commands can't be beaten anymore in
speed.

After all that happens:

Code: Select all

// step 1:

void BLT1(unsigned char *src, i16 *dst, i32 num, i16 *palette, ui8 *overlay)
{
    i16 ax, bx;
    bx = 0; // superflous
 do {
    bx = *overlay;  // extended from 8 to 16 bit - but doesn't matter
    overlay++;
    bx <<= 4;
    bx |= *src;   //Graphic nibble - high 8 bits of bx not affected
    src++;
    ax =  *(palette+bx);  // *2 comes because assembler doesn't do that two-byte-index-step that C does for an i16*
    *dst = ax;   //to screen bitmap
    dst++; // also just one ++ because of the same reason as before.
    } while (--num != 0);
}

// #####################################

// step 2:

void BLT1(i8* src, i16* dst, i32 num, i16* palette, ui8* overlay)
{
   for (i32 i=0; i<num; i++) // ecx is hidden in the loop-command
      *dst++ = palette[16*(*overlay++) | *src++];   // palette[n] is a 16-bit-color-representation

}

The palette index byte is built that way:
o o o o s s s s
So the left nibble comes from the overlay byte, the right nibble from the source.
Just imagine you got 16 16-color-palettes, overlay selects the palette then, source the color within the palette.
Btw: A good optimizing compiler can do that probably too. Using asm-commands makes your program dependent on one target. not good - not good.
If necessary add the keyword register to a local variable-definition to ensure that the one or other variable gets kept in a register. You may also take a look in the assembler-code while debugging. That's always available. After some confusion in the beginning, once that you get the idea, even 386+-assembler is readable. I just made this experience.

[Bit]

One more informations about the drawing done in CSBwin.
All drawing routines are still kept in the original Atari-graphics-format, which is as weird as can be.
Because you'll ask sooner or later anyways:
16 possible colors = 4 bit per pixel. But - they aren't organized linear, so you don't have 2 pixels in one byte.
Instead you got 4 words - for each bit(plane) one, that represents 16 pixel at one time.
Whereever you want to paint one pixel, you have to find out in which of those groups and at which position it is, and then mask in the color in each of the four bitplane-words. Now imagine what this means for clipping etc.

16 pixels (0-f) and their 4 words (8 bytes):
01234567 89abcdef 01234567 89abcdef 01234567 89abcdef 01234567 89abcdef
|---- color bit 0 --| |---- color bit 1----||---- color bit 2 ---||---- color bit 3 ---|

Whatever you do now, i.e. kick the original stretchblit-routine and take Allegro's one, the effect will be: it isn't an absolutely exact representation of the original graphic in the screen - i.e. the chest really will not look familiar anymore - you spot that on the first view. Then lighting and whatever (2nd color for some monster classes) adds - all that is already included in those original routines. Now explode that...
All my truecolor-drawing-routines keep the frame of the original routines and just expand them - that's why I got faith that they can be built into CSBwin one day - if no other interrupt occurs...

[Rasmus]

Thanks bit, this helped alot..
I managed to write to the graphics in a correct way. And now I am trying to read it..
I must say that I hate this even if I find it interesting.
each plane is 16 pixels wide.
And when I write color 0 to the first pixel the format comes out like this: 0 | 0 | 0 | 0
If I write color 1 to the first pixel the result is: 128 | 0 | 0 | 0
And it goes on like this:
0 | 128 | 0 | 0 (color 2)
128 | 128 | 0 | 0 (color 3)
0 | 0 | 128 | 0 (color 4)
128 | 0 | 128 | 0 (color 5)
0 | 128 | 128 | 0 (color 6)
128 | 128 | 128 | 0 (color 7)
0 | 0| 128 | 0 (color
128 | 0 | 0 | 128 (color 9)

By increasing the pixel (x) to 1, 2, 3 changes the values:
128 (0)
64 (1)
32 (2)
16 (3)
8 (4)
4 (5)
2 (6)
1 (7)
and then goes negativ...

and so on.. There is a system, but I am getting annoyed at it :S Will look more into it tonight.

[Paul Stevens]

This is a standard 16-color 4-bit-plane map as
implemented in every VGA-compatible video card.
If you run DOS programs in color, you are likely
to be using this mode of color mapping.
It made many operations quick to execute in
the CPU. The card had functions that did a
little bit of the masking operations and such
for you in some cases. The Atari had no
such help. It gave many people brain-seizures.

[Rasmus]

hehe, understood
But I am wondering.. Shouldn't the BLT1 function describe this procedure because it moves the atari graphic bitmaps to the bitmap for the backbuffer? And in that case, can't I use bits' translation of the function?

[Paul Stevens]

Shouldn't the BLT1 function describe this procedure

Good grief. Getting it to work was hard enough. Now you want
me to document it?

The CE version of these functions has no assembly code. And I
think they are probably about as fast.

can't I use bits' translation of the function

You can use any translation you please. You needn't ask me.

[Rasmus]

No, no, I didn't want you to document it, just wanted a hint if I was on the right track And if I were, I could use Bits' translation of your BLT function..

Thanks for the translation bit, it helped me alot. I can now read the atari viewport graphic and merge it with the truecolor bitmap that Paul uses as backbuffer to the window, this will come in handy later so that I just can draw all the stuff like the inventory, mousepointer, sleepmenu etc. right on my own viewport.

I can't say that I have learned it totally, but I have created functions that will come in handy for writing and reading the atari graphics

And here comes the good stuff. I have been able to use OpenGL in the viewport.. Meaning that I can now go on and create CSBWin in 3D, something like I did with the DMJavaOpenGLEngine

Here is a simple screenshoot on the 3d rendered walls. I will fix with it later so that the fog will be more DM like

[Paul Stevens]

Very impressive. Remarkable skills to be able
to dissect such gobbledygook code so quickly.
I'm excited to see where you are going with this.

[Bit]

Annoying - he destroys my plans for the next five years....
(We shouldn't train him anymore - we're going to create a monster )

[Sphenx]

(We shouldn't train him anymore - we're going to create a monster )

The aspect of his avatar was telling this anyway.
Rasmus, can you tell me : you can use your OpenGL renderer both in your DMJavaOpenGLEngine and CSBWin?
That can be an interesting improvement over the original engine - Would you also be able to manage continuous light rather than stepped light levels? But I have just one little question that tickles me : in your engine, when the player moves on or turns, is the 'smooth' animation between two positions 'stopping' game time (like in Lands of Lore) or not (like in DM2) ? I ask you because I had some plans to make also a 3D engine and was wondering about that specific point, so wanted to know your point of view?

Annoying - he destroys my plans for the next five years....

Some of mines too ... Have you tell him to create an OpenGL renderer for making a DM2 in 3D

[Bit]

Nono - this secret will be kept !

(you really wanted to?)

[Rasmus]

Thanks all
I have uploaded a version of CSBWin in 3D, it is still a bit simple and only 3D renders the walls. But I think you all get the point
http://dmtribute.webs.com/Files/CSBWin3D/CSBWin3D.zip

I will be back in a couple of hours again on the forum and explaining what I have done and answer your posts (I am a little bit in a hurry now..)

[Gambit37]

Rasmus, the screenshot looks cool. But the eye level is wrong -- it makes the player appear to be about 2 feet tall. Can you move the camera up a few "feet"?

[ChristopheF]

I get this error:

Code: Select all

The program can't start because cg.dll is missing from your computer. Try reinstalling the program to fix this problem. 

[Rasmus]

Auch.. cg.dll have to do with the opengl rendering, I can add it to the zip tomorrow..
Meanwhile you can just download it here http://www.driverskit.com/dll/cg.dll/320.html

[Rasmus]

@paul: Thanks.. I will give the forum the source code later on as soon as I have get everything working as it should
This wasn't accually as hard as I thought it were going to be.. What I did was letting OpenGL render to it's own backbuffer. But instead of letting it swap the backbuffer with the frontbuffer and so on. I copied the backbuffer to a texture, and the using this texture to draw right over the CSBWin viewport texture. And when this done, I could play around with OpenGL as much as I wanted too without affecting any other graphics in CSBWin.

@bit: Not my meaning to destroy any future projects I just get so exited when getting one thing to work I just can't stop trying on the next thing. My head is full with ideas right now.. If I only had more time

@Sphenx: Coding OpenGL in Java and C++ is accually the same thing. So I could just port the Java code to C++ and let the OpenGL coding be the same, and as I mentioned above, now when I can render with OpenGL right to the viewport there is nothing stoping me from just using the same technic as I did when creating the Java OpenGL engine.. But now as I have reserched the CSBWin code, I can use alot of the information there to make the engine more effective, so I will not do it in the exact same way
Continuous light will be a easy input, the same can go for fireballs lighting up walls etc. The CSBWin3D I released now stops the CSBWin engine while rendering the movment, but I only added this for this demo.. I have everything fixed for just letting OpenGL run on the side of CSBWin (Must be done in this way, because otherwise I would get strange monster/items/spells movement between squares), but it acts alttile bit choppy right now when letting them run side by side.. The viewport can be rendered at 1000 fps with the openGL engine on my computer, so all I need to find is a nice loop in CSBWin where I can render the viewport continuously at 60 fps.. If you are going to create a 3d engine by your own like DM, it must be done in this way. Think of this senario: If a monster moves from one point to another, and it takes him 1/6 of a second to do this, then your party will be frezzed while he is moving not to stop his animation.. But there are another way to do this even if it is not compitable with CSBWin: If you do all the monster movements and party movements etc every 1/6 of a second, then you have 1/6 of a second to animate everything at the same time untill the next monster / party / item / spell update. This method can be simpler to do in my point of view, but the game may seem alittle bit non floating..
A important input here is that you don't give the monsters floating positions between the titles and instead use integer positions. First move your item to the title you are going to move it to, then let the graphic engine animate this item so it would seem that the item is on it's way even when it accually already reached its destination already.. By doing this it will be more stable.. Even if the graphic output will come out wrong somehow, the system will always be correct and you can debug it more easely when it is not merge with the graphic and vice versa.

@gambit: I know about the viewport problem, but the fact is that when a wall is in front of the party it has the exact same position and dimention as the original DM. If you look at a screenshoot at DM you can see that the view is somehow unnatural because viewport direction accually is facing a bit downwards (this can be seen in a corridor), but if the view accually were looking downwards a wall in front of the party also would have some angle, but it hasn't.. I can't do so that the camera faces downwards, because then the walls facing the camera would tilt on the x-axis and not be squarish as in DM.
But I have some ideas to fix this:
I can create a fake angle by increasing the y-value on the vertexes in the viewport depending on how far away from the camera they are.. Hope it will work, because I want the walls to have the exact same view as in the original DM, otherwise I would have to go in and poke around in CSBWin. If the view isn't the same, I can't use the same mouse coordinates for picking up items from floors and buttons on walls, and that would be a serious problem

[Rasmus]

Also wanted to add this..
In CSBWin there are alot of memorylocations that have bitmaps for the DM graphics..
I had alot of problem getting them converted to regular rgb format. Therefore I would like to share the code on how to read these dmbitmaps and render them to normal bitmaps.
The Bitmap rendered is a "unsigned char[x*y*3]"
x for the x-position on the bitmap
y for the y-position on the bitmap
and every position has 3 unsigned chars for the rgb colors that range from 0-255.
So to get the green value at (10, 40) this is the way to go:

colorGreen = bitmap[((10*40) * 3) + 1];

And here comes the code for extracting the DM graphics inside CSBWin:

Code: Select all

int getAtariColor(pnt A1, dReg D0)
{
	bool c1 = false; if (wordGear(A1+0) & LE16(D0W)) c1 = true;
	bool c2 = false; if (wordGear(A1+2) & LE16(D0W)) c2 = true;
	bool c3 = false; if (wordGear(A1+4) & LE16(D0W)) c3 = true;
	bool c4 = false; if (wordGear(A1+6) & LE16(D0W)) c4 = true;
	return c1 + (c2 * 2) + (c3 * 4) + (c4 * 8);
}

void DrawAtariBitmap(pnt dest, 				// The memory adress to the dmbitmap
		     unsigned char *bitmapbuffer, 	// The bitmap to render too
		     i32 x0, 				// X-position on the bitmap to render too
		     i32 y0, 				// Y-position on the bitmap to render too
		     i32 destWidth, 			// The width of the dmbitmap
		     i32 drawWidth, 			// Drawwidth
		     i32 drawHeight,			// Drawheight
		     i16 maskColor, 			// Mask color
		     i32 destFromX, 			// Start at postion X when getting graphic from the dmbitmap
		     i32 destFromY, 			// Start at postion Y when getting graphic from the dmbitmap
		     i16 *palette)			// The bitmap palette
{
	for (i32 y = 0; y < drawHeight; y++)
	{
		for (i32 x = 0; x < drawWidth; x++)
		{
			if ((x0 + x >= 0)&&(y0 + y >= 0)&&(x0 + x < 224)&&(y0 + y < 136)) // This is the bounderies for the bitmap I am rendering too
			{
				// Calculate the memory location for the specific pixel at the dmbitmap
				i32 x1 = x + destFromX, y1 = y + destFromY;
				i32 d;
				dReg D0;				
				aReg A1, A2; 
				A1 = dest + (y1 * (destWidth / 2));
				d = (x1 >> 4);
				i32 d1 = d << 3;
				A1 += d1;
				i32 xonline = x1 - (d * 16);
				D0W = 65536 / (2 << xonline);
				// Get the colorindex at the specific memory location at the dmbitmap
				int colorID = getAtariColor(A1, D0);
				if (colorID!=maskColor)
				{
					// Converting the dm palette to r, g, b colors
					int b = palette[colorID] >> 8;
					int g = (palette[colorID] - (b << 8)) >> 4;
					int r = palette[colorID] - (b << 8) - (g << 4);
					// The output colors are in the range from 0 - 7
					r *= 32; g *= 32; b *= 32; // Converting colors to the range 0 - 255
					// Index for the pixel x and y coordinate calculation
					int index2 = (VIEWPORTHEIGHT - (y0 + y)) * 3 * VIEWPORTWIDTH;
					index2 += (x0 + x) * 3;
					// Write r g b colors to the bitmapbuffer
					bitmapbuffer[index2 + 0] = r;
					bitmapbuffer[index2 + 1] = g;
					bitmapbuffer[index2 + 2] = b;
				}
			}
		}
	}
}

@Paul:
I don't know if you have been around a looked at the pointer in DM? But that one really gave me a headace..
CSBWin created a new bitmap for the pointer every time it moved..
The bitmaps dimentions got changed depending on where at the screen it was (something like width + (the rest from x/16))..
And this bitmap also got diffrent dimentions depending on if it were an arrow, hand or item..
And because of the diffrent dimentions, the output arrow position also got wrong.. grrrrr..
Took me 3 hours to get this right

[zoom]

Rasmus, nice project.
concerning Lands of Lore vs. DM2
I would vote -if possible to not stop game time.. Sphenx, what had you in mind about this? Any opinions?

[Rasmus]

I also have a question to anyone that have been digging inside the CSBWin code..
I want as much original graphic as posible in the game.. The roof and floor have to be taken from elsewhere, but almost all other graphic can be used..

So at the start I want to load and convert all the graphic into bitmaps for opengl to use when rendering the 3D dungeon..
Do anyone know a good starting point on how to get all the graphic addresses?

[Sphenx]

@Zoom: same as you, not stopping game time. This because I manage a game engine by separating the gfx renderer from the game engine itself, then moving/turning animation would not stop the game. This way I can adjust fps independently from the game time speed.

[Gambit37]

@Rasmus: I don't understand the maths behind the camera issue, but it really does need fixing. Your one-point perspective is all wrong for a human sized player.

[Rasmus]

I know, just wanted to explain why I was having problem with it, and that I found something interesting about the dm viewport perspective when I looked at it..

A little risk of boring you out I made a picture showing that the first wall has the right height.. But when I create a wall further down the corridor it gets all wrong because of DM:s weird perspective.. But maybe it is just me that havent figured it out yet


I will work at it tomorrow..

Btw, has anyone been able to run it? Haven't heard from Christophe and I just wanted to know if I need to add more files than cg.dll..

[Rasmus]

I noticed that cgGL.dll also was missing...
I have replaced the arcive and added the necessery dll files:
http://dmtribute.webs.com/Files/CSBWin3D/CSBWin3D.zip