Sorry your browser is not supported!

I have around 20 or so FPS games written in DB. They are all very similar and follow a pretty standard template. When I got DBPro I used one of these games as a conversion exercise to learn the differences between the two implementations of Dark Basic. I thought it would be a reasonably trivial exercise, but how wrong I was...

Here are the things I needed to do in order to get a working version of my 3000 line DB game running in DBPro. As an aside the game itself cannot be posted here as it makes 'Postal2' look like 'Rainbow Islands', however my intention is to make it available free on my site (also, alas, too extreme to be advertised here) after making some further DBPro-specific modifications to it:

1) SYNTAX
I discovered some specific syntactic constructs (there are almost certainly more) that can no longer be used:

SELECT GiCharAct(iChar)
CASE DBA_WALK
ENDCASE
CASE DBA_RUN
ENDCASE
ENDSELECT

has to be replaced by something like this:

SELECT GiCharAct(iChar)
CASE 1`DBA_WALK
ENDCASE
CASE 2`DBA_RUN
ENDCASE
ENDSELECT

also a construct such as:

IF iX=0 THEN iZ=0:RETURN ELSE iZ=1

has to be re-written as:

IF iX=0
iZ=0:RETURN
ELSE
iZ=1
ENDIF

These are comparatively trivial problems, although the limitation on CASE usage can potentially make code harder to read

2) SPLASH SCREEN
While waiting for the program to load in all the images and sounds to be used in the game, it displays a splash screen

LOAD BITMAP "Splash.bmp",31
COPY BITMAP 31,0
SET CURRENT BITMAP 0

for some reason the above code fragment no longer works. However, this does (don't ask me why - although I have a sneaking suspicion):

LOAD BITMAP "Splash.bmp",31
COPY BITMAP 31,0
SET CURRENT BITMAP 0
WAIT 1

3) SKY DOME
I used a SPHERE object for the sky. I think there are other ways of doing this in DBPro, but my intention was to convert a project on a like-for-like basis, so I perservered with that technique

The code in DB went something like this:

POSITION OBJECT GiSky,GiMyX,0,GiMyZ
SCROLL OBJECT TEXTURE GiSky,GdWindSpeed#,0
FADE OBJECT GiSky,0

To get it to work as expected I had to remove the FADE OBJECT command, and lo! clouds raced across my sky as before

4) SOUND FILES
some sound files that DB was happy to load, will be rejected by DBPro. This seems to be down to the format of the WAV file, although I'm afraid I can give you as much help on this as the compiler gave to me. That is - none

5) MOUSE-HANDLING
My mouse-handling routines went screwy in DBPro

code such as this:

IF MOUSEMOVEX()<0 THEN GiMoveL=1
IF MOUSEMOVEX()>0 THEN GiMoveR=1
IF MOUSECLICK()=2 THEN GiMoveF=1
IF MOUSECLICK()=1 THEN GiFire=1

needs to be converted to something like this:

GiMouseMoveX=MOUSEMOVEX()
GiMouseClick=MOUSECLICK()

IF GiMouseMoveX<0 THEN GiMoveL=1
IF GiMouseMoveX>0 THEN GiMoveR=1
IF GiMouseClick=2 THEN GiMoveF=1
IF GiMouseClick=1 THEN GiFire=1

The above is probably the only time during the conversion where I could truly say that my initial DB code was a pile of pants and deserved to fail in DBPro

6) OBJECT TRANSPARENCY
I use 'pseudo-sprites' for enemies in my games. These are not true DB Sprites, but rather they are created like Duke Nukem or classic Doom sprites - in DB by using MAKE OBJECT PLAIN and then passing a series of images to the object to create animations of walking, shooting etc. When I first got to the point of seeing my game run in DBPro the first thing I noticed was that the black colour was not showing as transparent, but was just showing as, well, black!

Unfortunately there is a bug in the Help which made this problem harder to solve than it should have been

This was the old code:

MAKE OBJECT PLAIN iObj,iWidth,iHeight
SET OBJECT iObj,1,0,1

This is what is required in DBPro:

SET IMAGE COLORKEY 0,0,0
MAKE OBJECT PLAIN iObj,iWidth,iHeight
SET OBJECT iObj,1,1,0

Or, to be a bit more trendy and up-to-date:

SET IMAGE COLORKEY 0,0,0
MAKE OBJECT PLAIN iObj,iWidth,iHeight
SET OBJECT TRANSPARENCY iObj,1

7) FRAMERATE
I said that the game ran - well, that was true but it ran like an absolute pig through treacle. Obviously I thought this must be down to something like SYNC RATE or - well, anyway, lots of complicated things. The last thing on my mind was that it could be caused by the INK command! However, that is exactly what the fly in the ointment was. I display things like score and life on screen during the game and these are contained in a little subroutine within the main game loop

The offending code was something like:

INK RGB(10,100,0),RGB(0,0,0)
TEXT 7,1,"Life:"
INK RGB(0,169,0),RGB(0,0,0)
TEXT 85,1,STR$(GiMyLife)

removing the INK commands and everything came back up to speed, although now my Score and Life displays obviously look a little less colourful, as they are now displayed using only the one colour. I believe from other correspondence that in fact any commands that modify text-related attributes (such as FONT, SIZE etc) should also be avoided from within the main game loop

=========

So - that's it. I'm a very simple programmer, so I'm sure that there are loads of other, more complex things that I never used in the first place which worked one way in DB and a different way in DBPro. I'll leave those for cleverer people to find and list

I know that I am not the first person to discover these issues, and that many of these problems and their resolutions can be found elsewhere in the forums - however it seemed a worthwhile exercise to collate them all in one place

While I was going through this exercise I posted a number of whiney pleas on the Forums and I would like to express much thanks to all those people who went out of their way to help out a newbie here

Hopefully the above notes might be of some small assistance to anyone else contemplating conversion from DB to DBPro. The bottom line is that even without any DBPro specific modifications (other than to get it running) my game actually looks a lot better than it did before, so I am now really looking forward to polishing it up even further

No - as long as DBA_WALK is a constant, you're okay. This works :



but not




Yes, because that is badly formed basic


Works fine here.


Dont see why...


Its possible that INK does a lot more that it like it should, although I think its more likely the TEXT command thats causing the slowdown.

Can someone test this :



It crashes the compiler (but still runs). Keep the comments, they seem to cause the problem.

Hey TCA

That code works perfectly for me and doesn't crash the compiler. It displays just the frame rate (which is about 150fps in dark green), if I un-rem all the lines out than the 3 lots of text show up "Life", "0" (in dark green) and the frame rate (a scary 75fps in a lighter green).
I'm using DBP 5.5 just incase you wanted to know.

pizzaman

Are you using XP Professional ? If not, it could be related to that - it always comes up with a problem in MSVCRT.DLL
The odd thing is, if I remove the second comment, all is fine. Put it back in, and its a problem.

Works here using WinXP professional SP1 and Patch 5.5.

When text commands are remmed: 495 fps
when unremmed: 70 fps

Sorry - forgot to mention, you need SP2

I get 850/200 respectively myself. I'm running winXP SP1, DBpro 5.5.

My system is just a p4 2.66gig, 512mb DDR333 RAM, and a 128mb Geforce FX 5200 ultra.

I have no problems with anything crashing whatsoever.

Wonder if its an SP2 problem then...

It is always a possibility. Has SP2 ever been officially released yet?

Thanks for the info, HC. I think I have suffered in similar ways to yourself. You can do certain things in DBClassic, that theoretically you shouldn't, but DBC lets you get away with it.

The biggie for me was the CASE statements. I used the fact that you could do a case comparison on a variable, which I know as a programmer is silly...but it let me do it so I did! I was actually comparing two variables, with changing values, in case statements.

There are also some real niggles, such as the INK issue and the transparency inconsistencies, which are plain annoying.

No - it SP2 will be in a few weeks though.

thanks for the feedback:

i didn't know about constants. shows how dumb i am. but now i've learned something and am a little less dumber, and will use constants in future

i also swear by almighty god that i will never use badly formed basic in the future (even when the compiler - the old naughty compiler - lets me)

on the mouse thing i'd have thought it was obvious that it shouldn't work, and trust me, it doesn't

on the splash screen thing it isn't obvious why it doesn't work, but trust me, it doesn't

on the text thing it isn't obvious why it should be the INK command and not the TEXT command that slows everything down, but trust me, it is

(the above three statements are derived from empirical observation of my own real life example, but may of course not be applicable in cases other than those from my own little programming island)

BV - although i didn't know about constants as defined in DB, the variables i was using in the case statements were effectively constants (in other words, defined once and never modified)

however - i actually got a compiler error telling me i couldn't do what i was trying to do (in other words the exe never got as far as running at all), so i'd be surprised if that was the root of your own problems?

as a p.s. about constants, it's probably my old man's eyes not being as good as they used to be, but i've scoured the documentation and i can find no mention of constants anywhere, so i don't feel quite so dumb any more (ok, i am still dumb, but that's another story)

however, while i was doing that i discovered that you can have user-defined types, which i also didn't know before, and that is definitely going to come in handy

2 more gotchas:

now that i have a viable running DBPro version of my game, i am finally making the kind of mods that i expected i'd been making when i first started the exercise (i.e. tweaks of small things that were incompatible between DB and DBPro)

1) all my 'sprites' seemed to be walking backwards! strange. then i noticed that the images were all actually reversed. anyhoo, after some digging around it would appear that setting the orientation towards the camera position now does what it probably was meant to do in DB, in other words it sets the object to look in the same direction as the camera and not TOWARDS the camera (which is what happened in DB). this problem was easily solved by adding a YROTATE after the SET ORIENTATION TO CAMERA (can't remember what the specifics of the command are)

2) i haven't solved this one yet, but is there something weird with GHOST MATRIX? i use a ghost matrix for creating a ground mist effect, but the matrix always appears in the centre of the screen - if i REM out the ghost matrix command then i see the 'mist' matrix in its expected position just above the lower level 'ground' matrix. after posting this i'll toddle off and search the forums

p.s. i love the way some command Helps go something like: GHOST MATRIX matrix number, ghost flag... and then say nothing about what the 'ghost flag' or whatever does. i suppose it's to make us try them out ourselves

an a p.s. i've discovered that i actually use INK within the game loop in another context (to create an onscreen map) and that DOESN'T slow the game down

so, er, it must be the specific INK/TEXT combination that brings it grinding to a halt

probably

"you can have user-defined types, which i also didn't know before, and that is definitely going to come in handy"

mm not as handy as you might think. you aren't allowed to have arrays in types and you may not pass types by reference. which means no passing in a type to a function to be modified (which is usually what one wants to do..).

"is there something weird with GHOST MATRIX"

i believe the SET MATRIX PRIORITY command is what you're looking for here.

my experiments with INK have shown it to be painfully slow but only after a certain number of uses. i have no idea what else they would be doing besides changing two internal variables. HOPEFULLY they're not reloading the font on every INK command like all the other font property commands

as for your mousemovex/y() problem - mousemovex/y() in DBP pre-5.4 returns the movement of the mouse since the last call to the command. but this was supposedly fixed in P5.4. did you update yet?

and your splashscreen problem - try a SYNC instead of a WAIT and see if that does it.

thanks for the advice. i'm going to try playing with the matrix priority thing when i've lost my hangover...

...god i am never going to drink so much ever again


probably