Dungeon Master Forum

Rasmus wrote: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?

graphics.cpp:
void ReadGraphic(i16 graphicNumber, pnt buffer, i32 maxSize) // TAG021af2

BUT - graphics are loaded when needed and not already cached.
Next problem is, the datastructures to control the cache are simply evil and not handable in C++, because they do have variable size. In some situations they even target the graphics-structure n+1 instead of n and seek back some bytes for the datas at the end of graphics-structure n - that's really pretty dirty. Maybe make a second layout (like I did - with never deleting a graphic anymore once loaded - assuming we got a lot of memory nowadays).
Get http://www.akluwi.de/dmcsb/src/rasmus3.zip for my latest working truecolor/hires-versions and study gfx.cpp. All graphics are included as png-files as well (without masks!).
You may also take a look into draw.cpp how I patched all those drawing routines.

in most cases my routines got a reference to the original DM-label like L_012345 (at least in the header-files). You'll also find a file syn2.cpp in the common-folder. There you find the corresponding T_98765-label of CSB - and if you then search in CSBwin for TAG98765, you'll find the original there.

Checking it out right away Thanks!

Hey, you're too fast again - it's still uploading (Check again the last post, I did another edit in the end).
tsktsktsk - unbelievable

okey, okey

I have a rather cheating idea for how to get all this to work without importing any graphics to fit with the opengl.. Please tell me what you all think..

I searched the drawing routines in CSBWin, and found functions like:
DrawCellF1(), DrawCellF2(), DrawCellF1R1() --- (Thanks for your detailed describtion Paul )
All these functions later on calls functions like:
DrawFloorDecorations(), DrawWallDecorations(), DrawRoomObjects()
and also send data like what cell that are going to be rendered..

Inside DrawWallDecorations() the graphic that are going to be written has the varible "A2", and is writing to d.pViewportBMP.

Now here is the idea:
- At the init OpenGL I create 12 bitmaps, one for each cell that wall-, floor-, celling-, roomobjects can be drawn to..
- Every time the DrawViewport() are called, I clean these bitmaps with a mask color.
- After this DrawFloorDecorations(), DrawWallDecorations(), DrawRoomObjects() are called when some of these objects are going to drawn to the d.pViewportBMP.
- Now, instead of drawing to d.pViewportBMP I instead make CSBWin draw to one of these 12 bitmaps I created before, or more specific, draw to the bitmap with the corresponding cell.
- When openGL later on will render the viewport I will have 12 bitmaps with all the graphic needed..
Let say that bitmap 4 is the cell that are front-right of the party with two wallobject on it, then bitmap 4 will look like this:


And if I skip the part with drawing walls, then I will have all the objects isolated with the maskcolor surounding it. Like in this picture:


The red part defines the texture that I will draw over the the front side of the cell with red as masking color, and the green part defines the texture that I will draw over the the left side of the cell with green as masking color..

By doing this, and that it will look ahlright.. I will have every object used in DM, CSB, conflux graphic etc inserted into the OpenGL 3D engine without any extra work at all, and this goes for everyone using it

There are probably some downsides that I haven't thought of yet, but I will just have to wait and see..

Is it possible to change the headline of this topic to: "Converting CSBWin graphicengine to a OpenGL 3D engine"?
/ Thanks in advance

You should be able to edit your own first post to make the subject whatever you want.

Fixed, thanks beo

Works for me I did find an anomoly though - in a few places I am stopped from moving forward even though the corridor continues?!?

@money, I would have said that too. When I launch that CSBWin3D, I do not have any objects visible (wall or floor), then the "invisible" wall is when there is a closed door, and it stops you.

Here's another idea - maybe in combination
Insert in each drawing routine something like a command with parameters that is stored in a list.
When it comes to the final bitmapcopy to the screen, you do something like parsing that list and you can decide how to draw.

Sphenx wrote:@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.

So, what is it then for Rasmus´s approach.. you are working on a separate thing, sphenx, no?
if there is a graphical - lagging through the game it would be horrible(or not nice)-
stopping game time is a no-go imo. It just does not feel right to stop dm´s engine!

So maybe - programming /technical issuewise the separation of gfx render from game engine would be something for Rasmus . I do not see that this is solved yet, or maybe it is?

It is a good thing that the game was playable The reason why you all stopped in the corridor i because all the engine do for now is rendering the walls and nothing else.. And normaly it is a door there blocking the way if you haven't choosed a champion.. If you press on a wall where you know there normaly is a mirror, you will get to choose it as normally. This just shows that the only thing affected is the graphic and nothing else..

@bit: I was thinking about that first, it would probably be the best way to get it most graphicly correct.. But I will by begin giving my idea a try because it is a fast fix, then I will change if it doesn't work as it should..

EDIT: have to add here that it is a fast fix because I don't have to worry about where the wallobjects, floorobjects etc. will have for position in 3d space.. Just copy the cellarea and paste it over 3d cell area

Just copy the cellarea and paste it over 3d cell area

sounds like a good idea!

The DM perspective is not something that is easy to duplicate using "proper" 3D, because the original version was all hand-drawn and I think they took some liberties. One big one I'm sure many of us have noticed is the issue of missing bricks; if you look at a wall from the front, you'll notice it has many more bricks than when you see it in a perspective view looking down the hall. The actual perspective in use is also something that isn't quite "real 3D," if I remember right.

In addition, basic DM is also quite well-suited to its one wallset--I know that attempting to code DSB and WHACK and get things looking sane using different wallsets required me figuring out things that the original engine never had to worry about, for example, the way the "distance 3 far wall" fades to black long before it would actually end, leading to the wall looking very wrong when things are brighter. Linflas might be able to assist, having actually designed a program that converts a true 3D rendering into walls that can be used in DM.

I think some angels when turning can show incorrect graphics, but we will see how it goes

I am working with it now and are having some minor issues, or big, don't really know yet..
I have noticed that CSBWin uses alloc and realloc, something I used at first with DMT2. But then I removed and replaced with a homemade memory management because of some instability..
Think some problem has come up because of CSBWin memorymanagement.
The file I am working with in CSBWin is named View3D.cpp, and it is here I am coding for the openGL.
Here is an example:
- I declare a int value: (int iTest = 0;)
- Every time the viewport gets drawn in CSBWin it calls a function in View3D.cpp.
- In this function I increase iTest with one (iTest++;)
- But every time I check what the value has become the value is almost always 0 or 1.

I think CSBWin uses realloc which allocates memory right over my declared values in View3D.cpp.
This is a major problem as I see it, and I think the only way to fix it is to declare all my varibles before CSBWin declares his varibles..
I don't know if there are another way to get around this

I figured something like that Sophia, and did some ugly calculations inside the OpenGL Vertexshader to get it to look almost correct.. I had to make the camera face alittle bit up without tilting the walls that are directly in front. I did this by increasing the y-axis the larger the z-axis where. Also the z-axis in DM isn't right either in comperensment to the x-axis. Just using OpenGL makes a wall two tiles away look very far away in comperensment to DM, so I had to make the z-axis smaller in comperesment to the x-axis..
Took me some hours calibrating everything to get it almost right, but I will wait and see what you guys think about it with the next upload

I declare a int value: (int iTest = 0;)

Local variable??? in a function??? If so, it needs
to be declared static. Else it is allocated on the
heap each time the function is called.

I don't think CSBWin does anything clever or not
standard for C++ programs.

No sorry, I may have explained it wrong..
Not in the function, outside all functions but still in View3D.cpp.
Then I just increase it with one everytime the function is called, but still it doesn't "remember" its valueincrease the next time the function gets called
It worked when I put the declaration in CSBWin.cpp and then used "extern int iTest = 0;" in View3D.cpp, THEN it remember its value and doesn't get "reset" everytime the function is called..

I think it is weird.. And the only reason I can come to think of why it is doing that is the use of "realloc"..

(The use of iTest was just an example, it does this to almost all varibles I declare inside View3D.cpp, more vital varibles . But I will just have to declare all my varibles in CSBWin.cpp instead and use "extern" in View3D.cpp to be able to use them, it's just a little bit annoying..)

If you are happy doing it that way....OK.

But I tend to try my best to understand such things.
Otherwise, they usually come back and bite me really
hard. Especially when there is more than one thing
I don't understand (a not-uncommon thing, unfortunately).

Just have a singleton for all your globals, so a class with one instance only.

Guys you are weird
I am so happy I didn't get past my basic Turbo Pascal lessons in elementary school and played UFO and Commander Keen instead

anyway, thumbs up!

New screenshoots:

Graphics now in use:
- Wallobjects
- Floorobjects
- Doors
- Stairs
- Dungeon light level

Still to insert:
- Roofobjects (roofpit)
- Blue Haze
- Items (with animation)
- Monsters (with animation)
- Spells (with animation)

I can't say that I am finished after that, because I have alot of experience on having to redo alot of stuff because of some kind of problem in the end :S

What I did here was that I copied each cellarea that have a objects and pasted it over a texture that later on was used in the 3d cell area. This wasen't as easy that it may sound, the Dungeon Master perspective forced me to calibrate everything that I inserted, and sometimes the result wasn't all that good.. As you all can see in the screenshoot down to the left when the camera is turning, the pressurepad is cut of. This was one of my mayor problems when I copied the DM cellareas, if the right part of the pressurepad isn't visible in dm, I can't make it visible when converting it into 3d.
But I have to add here that some objects only get cut like that when the camera is turning, and one turn takes about 1/6 of second, so it is not that it is noticeble if you are not focusing on it.. Larger objects like door also get cut of, this I may have to fix somehow, because that is more noticible...

I hope you all think the perspective is dm like now.. Had to fix with it alot to make everything come in the same place as in DM, otherwise it would be a problem locating a switch if it now has an accual position other than what is shown in the viewport.

@Paul: I agree with you, I also hate to leave things with a simple solution of the same reason as you said. But I am alittle bit afraid of poking around to much in the CSBCode trying to understand what went wrong, mostly because I am not that good at understanding CSB memorymanagement.. But I did found a sulotion that made the problem disapear. All I did was declaring all my varibles before including CSBWin:s header files. It isn't the best sulotion, but since the problem was from the start, I blame CSBWin and instead avoid it

@Bit: That is a good idea, will give me some more structure too for others that are searhing the code to find what I added where..

@Octopuss: Yeah, my friends says that about me too.. Holding on to a 20 year old game, something I avoid mentioning in some social situations Thanks for the thumbs

And here is the download for those of you that would like to check it out
http://dmtribute.webs.com/Files/CSBWin3 ... 01022).zip

I would like to get some comments about the gamespeed..
If the animation is slow and if it is slowing down the CSBWin engine.

Note: You can switch between the normal Dungeon Master view and 3D OpenGL view by pressing "F1".

This is too cool. Food for thought: In another thread I suggested moving the camera in a circular motion when turning (rather than a simple pivot).

Yeah, I tried it for a few seconds before leaving for work - very cool to see the pivot. Oddly, in complete darkness the monster (mummy) seemed to be invisible at the doorway.

The movement seems a little slow, but hard to know if that is just compared to the normal DM jumps in movements. I don't believe it was slow due to my processor or anything.

I don't believe it was slow due to my processor or anything.

Maybe was your internal human clock that ticked too slow then. You just ate?

Or video card issue? Can that be?
It runs well for me. Even too fast if you don't release the arrow keys.

Oddly, in complete darkness the monster (mummy) seemed to be invisible at the doorway.

Rasmus said he hasn't inserted creatures yet.

In another thread I suggested moving the camera in a circular motion when turning (rather than a simple pivot)

I missed that thread, I don't visualise that "circular motion". What is it?

@Rasmus: what do you use "darkness.bmp" for?

Odd, I was blocked where the mummy would have been, even thought the door was opened, and then I bashed successfully and could get through. Is it possible the graphic is deleted but the dungeon still has the mummy there?

I did realise the dungeon was very unpopulated when I missed the gold key at the start of level two

Sphenx wrote: I missed that thread, I don't visualise that "circular motion". What is it?

Basically keeping the camera some fixed distance backward from the center of the cell (the center is always ahead of the camera's position in a top-down view). So when rotation, the camera pans along the circle of that distance as well.

The mummy is definitely in there, but invisible. He attacked me.

Nice implementation of a 3D engine, this looks very promising work