Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Discussion / Uncapping the 60 fps lock!?

Author
Message
Ashingda 27
16
Years of Service
User Offline
Joined: 15th Feb 2008
Location:
Posted: 20th Jan 2009 00:59 Edited at: 20th Jan 2009 01:11
My pc is one of the few that's having the 60 fps capping problem. During one of a project my 60 fps cap came off by accident.

It seems if I Load Music from an mp3 file my 60 fps converts to what ever I have set as my refresh rate on my desktop.

I tried this in windows mode and the cap came off completely!

I'm not sure whether the bug is in DB itself that's making the fps lock or a bug in the load music command that's unlocking it, other's said it could be my machine that locks it.

Anyways, anyone who's experiencing a 60 fps lock, this might be an alternate way of getting around it. You dont have to use the mp3, you just have to load it.

I created an empty mp3 file for use with this.

Attachments

Login to view attachments
Robert The Robot
17
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 20th Jan 2009 16:26 Edited at: 20th Jan 2009 16:27
Yes, loading an mp3 as a piece of music will remove the 60fps caps lock. For some reason, this command disables what is known as VSync, a feature that locks a 3d application's refresh rate to your computer monitor refresh rate.

Latch, Irojo and I were working on a way to disable this VSync, and I stumbled across the fact that merely loading the "winmm.dll" (I found reference to it in a code snippet Latch made ages ago for loading Midi files without using DBC's native command set) would remove the fps cap, although none of us were able to explain quite why.

Your blank mp3 idea is great, but there is a catch which you may not have realised yet - it will only work in the DBC editor. To get the fps cap removed in standalone exe's, place the attached Setup.ini file with your exe when you distribute it.

You can read a little more about what we found here. Hope this helps!

"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."

Attachments

Login to view attachments
Ashingda 27
16
Years of Service
User Offline
Joined: 15th Feb 2008
Location:
Posted: 20th Jan 2009 18:05 Edited at: 17th Mar 2013 23:09
Wow that works wonderfully, thanks very much Robert the Robot.

[edit]

Wow I missed alot of usfull info on that thread!

Attachments

Login to view attachments
Phaelax
DBPro Master
20
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 20th Jan 2009 18:47
I thought this could be fixed by turning off the vertical sync in your display settings?

Ashingda 27
16
Years of Service
User Offline
Joined: 15th Feb 2008
Location:
Posted: 20th Jan 2009 20:31 Edited at: 17th Mar 2013 21:17
No I've tried that, it didn't do anything for me.

Attachments

Login to view attachments
Robert The Robot
17
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 21st Jan 2009 13:08
Quote: "I thought this could be fixed by turning off the vertical sync in your display settings?"

It can, I think, but you have to set VSync to "Force Off" or DB will revert back to its defaults and cap at 60fps.

If the setting is "Let 3d application decide" then DB again reverts back to its defaults and caps at 60fps, unless both "blitflipmode=1" is found in the exe's setup.ini file and an mp3 is loaded as a piece of music.

"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 21st Jan 2009 18:34
@Robert The Robot and @all

With all your knowledge of how to install DBC on Vista, your investigation into the 60fps cap, and all the other little tidbits that have been been put into threads regarding things like: build exe, build final, setup.ini, text using character sets and the general - getting started information on DBC, maybe we users should draw up a thread that has all of this listed in one place.

Though this may be high-jacking Ashingda's thread, with Ashingda's approval we could draft it here putting together all the information including the upgrade link, the link to TDKs tutorials, a link to the monster hunt and binary moon tutorials etc.

When enough information has been collected that we want to include in the thread, the real thread can be created with an appropriate title that will allow a search to zero in on it; inluding words like Install, Vista, compile, build, final, exe, setup, etc. in the title (so that it makes sense and allows a good search return).

What do you think?

Enjoy your day.
Ashingda 27
16
Years of Service
User Offline
Joined: 15th Feb 2008
Location:
Posted: 21st Jan 2009 18:49 Edited at: 17th Mar 2013 21:17
Great idea Latch, these info should be easily accessible to anyone needing it.

Attachments

Login to view attachments
Robert The Robot
17
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 23rd Jan 2009 13:32
@Latch and Ashingda 27
I've been giving this a bit of thought, do you think these explanations would be any good? (I've never written a tutorial before )

Getting DBC to work on Vista
Exe’s built using DBC v1.13 or older would start by writing temp files to the ‘C:\Windows\Temp’ folder. However, in Vista this folder is locked and cannot be edited unless the current computer user is running as an administrator. To allow Vista compatibility, DBC 1.20 (also known as DBC 1.14) changed the folder used to hold temp files to ‘C:\dbTemp’, where ‘C’ was the drive that the exe was located on.

If the folder ‘<root drive>:\dbTemp’ cannot be created, then the exe will fail to load and will instead show a blue splash screen that is normally only seen when the user exits a program made using the trial version of DBC. It is, therefore, impossible to run a DBC exe from a write-once CD, since the program will be unable to create or edit the contents of a temp folder on such a disc. Instead, you have to copy the exe and all associated media to a folder on either the hard drive or a pen drive and the exe will run normally.

Something else to bear in mind is that while the dbTemp folder is created automatically, it is never actually deleted. After the exe is closed, the files ‘_virtual.bmp’, '_virtual.dat', ‘_virtual.jpg’ and ‘_virtual.wma’ can exist, so when your program terminates, you may want to call this code:


It’s not essential, but it could be a good idea, both as a cleanup measure and as a way of preventing others from being able to access parts of the media used by your program.



Removing the 60fps lock

You may have noticed that no matter what you do in DBC, you can’t make your programs run faster than 60fps – you can’t make the monitor show more than 60 images a second. Even a piece of code as simple can’t do it:


This isn’t a technically a limitation of DBC, but something that depends on how you monitor is set up. Buried deep within your 3d display settings is a little parameter called VSync, which locks a computer game’s refresh rate to the monitor’s refresh rate – so if your monitor refreshes at just 60 times a second, no computer game you make (or run, for that matter) can put more than 60 images to your screen in a second.

If you’re wondering why this restriction was ever imposed in the first place, it was because some early computer games ran so quickly that they were sending a new image to the screen before the old one had been fully drawn, and so the screen began to show a flickering, disjointed mess – an effect known as ‘tearing’. This effect isn’t as much of an issue now, thanks to advances in software, but the limitation still remains to annoy DBC programmers.

You could just go into your control panel and set VSync to ‘Force Off’, but it’s far better (and easier for users on other computers) to leave it set to the default of ‘Let 3d application decide’ and make some adjustments within DBC itself:

1) Find and open the file ‘Setup.ini’, located with the file ‘DB.exe’. If you used the default install path, then it should be located in ‘C:\Program Files\Dark Basic Software\Dark Basic’.

2) Read through the file until you find the blitflipmode parameter, and make sure that the line says ‘blitflipmode=1’. This doesn’t do anything by itself, but it allows DBC to give higher frame rates if you do the next step. Don’t forget to save the setup file if you’ve had to make any changes to it.

3) Now you have a choice of what you want to do. You can either:
a) Load an mp3 audio file by calling ‘Load Music ‘myaudio.mp3’, MusicNum’. MusicNum can be any number you like. You don’t even have to play the music, but you’ll notice a sharp increase in frame rate. Note that this won’t work for a midi music file.

b) You could use the following code snippet to create a frame rate increase though using a midi file:



4) When you build your final exe, always place a copy of the Setup.ini file in the same folder as your exe. Without it, the DBC program will default back to locking VSync on, and you’ll still lock at 60fps.

Further Notes
The actual value of 60fps as the maximum program refresh rate will vary from monitor to monitor. Most modern LCD monitors are made to run at 60Hz (that is, they give 60fps), but some 120Hz monitors are around. Also, if you change the display resolution then you may be able to make your monitor refresh faster.

You should also be aware that some computers systems don’t have a frame rate cap – they appear to be ones with older versions of DirectX installed.



Reducing the 100% CPU usage

If you have a CPU meter on your computer, you’ll have probably noticed that whenever you run a Dark Basic program, one core of your CPU is always running at 100%. It is possible to reduce the CPU workload by making the program sleep for a short time each program loop. However, you shouldn’t use the DBC ‘Sleep’ command because this will make text drawn on screen appear to flicker. You have to load the Kernel32.dll, and call the Windows ‘Sleep’ function:


If you can review your CPU meter history after exiting the program, you should find that there will be a sharp peak for the first two or three seconds of running the exe, and after that the program will settle down, using around 40% of the CPU.

Why 40%? It’s because the exe is sleeping for 10ms after every sync, so at 60fps the processor spends 60*10 = 600ms lying idle. So, it must be doing all the work in just 400ms, which is 40% of one second!

With a bit more maths, you can work out how long each frame takes to be drawn to the screen and work backwards to ensure your desired frame rate. It takes 400ms to draw 60 frames, so it’s taking 400/60 = 6.6667ms to draw each frame on screen. For simplicity, let’s call it 7ms. If we want 30fps, then it will take 30*7 = 210ms to draw them on screen. We can let the processor lie idle for the remaining 1000-210 = 790ms, so the sleep period has to be 790/30 = 26.3ms (26 to the nearest integer). Plug in 26 to the above code snippet, and you can see it run at 31 to 32 frames a second.

So, in a nutshell the sleep time calculation is:

You have to be careful about the value you specify for FrameDrawTime – for my computer a value of 7 works well, but this will almost certainly be different for others and I’m not sure it can be calculated at runtime using this method. Because of the 60fps lock (discussed above) a sleep value of anything from 0 to 7 will still produce a constant 60 frames a second. If you read on, you’ll find a neat trick to sidestep it.


Increasing frame rates and freeing up processing power
By combining the above two techniques it is possible to achieve higher frame rates than 60fps, without running one processor at 100%. Try a code snippet like this:


This will return you to a maximum refresh rate of 60fps, but the processor is running at around 12%. There may be frequent processing spikes, but I believe this is due to Windows taking advantage of the fact that your program is ‘Sleeping’ and using the spare processing power for other things.

The sleep time may still be calculated using this formula:

but it now becomes possible to calculate the frame draw time. Call this code at the start of your program:


It works by allowing the program to run at its fastest rate for one second, so we can get access to an accurate Screen FPS() value. By dividing this by 1000 we get the length of time, in ms, the computer needs to draw one image on screen. We can then plug this value into the other formula, and work out how long the program can sleep each sync.

"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."
Irojo
15
Years of Service
User Offline
Joined: 21st May 2008
Location: Eating toast.
Posted: 23rd Jan 2009 16:22
Sounds like stuff for a sticky here...


Time is money. I just ripped you off.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 23rd Jan 2009 17:52 Edited at: 23rd Jan 2009 17:57
@Robert the Robot

Thank you for all of that hard work!

Looks good so far. Maybe we can shorten it up a bit. Also just for your own information in relation to DBC, SYNC RATE and FPS() are not the speed at which the screen is redrawn - exactly. SYNC RATE represents the syncronization speed of all the processes of the program. It orders the processes based on the timing value, and then when SYNC is called, all the values are updated. In DBC, I do not believe the actual redraw of the graphics information is ever faster than the settings of the graphics adapter. The graphics timing of the backbuffer to frontbuffer swap is at the hardware refresh timing. So a higher SYNC rate means faster processing but no change in the actual redrawing rate. At slow rates like 10, it would seem that the redraw is slower, it's not, it's just the refresh of all the processes values are held until the SYNC call - then the visuals are updated. If the redraw rate was actually the SYNC RATE, at a SYNC RATE of 1, you'd see the screen redraw slowwly from top to bottom. It would take a whole second to redraw the screen! It doesn't affect the redraw, it just runs the process timing within the iteration of a loop based on the SYNC RATE value.

Enjoy your day.
Ashingda 27
16
Years of Service
User Offline
Joined: 15th Feb 2008
Location:
Posted: 23rd Jan 2009 19:31 Edited at: 17th Mar 2013 21:18
Excellent work Robert The Robot!

Attachments

Login to view attachments
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 23rd Jan 2009 22:17 Edited at: 23rd Jan 2009 22:23
@RTR

I went through your post and added and edited a couple of things. Please review. The ITALICIZED text is what I think should be removed or changed. The UNDERLINED text are my additions or changes - in some cases just notes or questions to you.

Building a Final Executable

When you decide to build a final exe - a game or application that includes all of your media inside the exe itself - you want to make sure of a few things:

1) All of the media, the subfolders, and the source are contained in a single folder.
a) When you are adding media - such as Load Sound "gunshot.wav",1 - inside your source code, use relative paths. This means all the media is contained in the main folder where your source code lives or in subfolders of that folder. That means if your source is located at F:\myprogram but say all your sound files are at F:\program files\soundgame sounds, you'll want to copy the media into your F:\myprogram folder. You might even create a game sounds folder in your main folder: F:\myprogram\game sounds
When you load a sound in your source, the code might then look like
Load Sound "game soundsgunshot.wav",1

2) NOTHING EXTRA is in the main folder or any of the subfolders. That means no extra test graphics, no miscellaneous files, no other exes, no extra folders, no extra DLLs - NOTHING EXTRA. Only include the media files and/or the folders containing the mdeia files. If there are other files than the media you want included in your Final Build, they have the potential of being compiled into the exe. That means the exe:
a) could bloat to a ridiculous size. The largest it should be is about 1.7 megs + the size of your media
b) not function at all.

3) Once the final is built, move it to it's own folder including any text files, DLLs, custom files, or any other files that were Non-Media that are necessary for your program to run.
For example, if you used a collision DLL named 'Collision.dll', you would have removed it from the main folder when you were building the final and now would include it with the completed final exe in the proper directory.


Getting DBC to work on Vista
Exe’s built using DBC v1.13 or older would start by writing temp files to the ‘C:\WindowsTemp’ folder. However, in Vista this folder is locked and cannot be edited unless the current computer user is running as an administrator. To allow Vista compatibility, DBC 1.20 (also known as DBC 1.14) changed the folder used to hold temp files to ‘C:\dbTemp’, where ‘C’ was the drive that the exe was located on.

If the folder ‘<root drive>:\dbTemp’ cannot be created, then the exe will fail to load and will instead show a blue splash screen that is normally only seen when the user exits a program made using the trial version of DBC. It is, therefore, impossible to run a DBC exe from a write-once CD, since the program will be unable to create or edit the contents of a temp folder on such a disc. Instead, you have to copy the exe and all associated media to a folder on either the hard drive or a pen drive and the exe will run normally.

Something else to bear in mind is that while the dbTemp folder is created automatically, it is never actually deleted. After the exe is closed, the files ‘_virtual.bmp’, '_virtual.dat', ‘_virtual.jpg’ and ‘_virtual.wma’ can exist, so when your program terminates, you may want to call this code:


It’s not essential, but it could be a good idea, both as a cleanup measure and as a way of preventing others from being able to access parts of the media used by your program.



Removing the 60fps lock

You may have noticed that no matter what you do in DBC, you can’t make your programs run faster than 60fps – you can’t make the monitor show more than 60 images a second. Even a piece of code as simple can’t do it:


This isn’t a technically a limitation of DBC, but something that depends on how you monitor is set up. Buried deep within your 3d display settings is a little parameter called VSync, which locks a computer game’s refresh rate to the monitor’s refresh rate – so if your monitor refreshes at just 60 times a second, no computer game you make (or run, for that matter) can put more than 60 images to your screen in a second.

If you’re wondering why this restriction was ever imposed in the first place, it was because some early computer games ran so quickly that they were sending a new image to the screen before the old one had been fully drawn, and so the screen began to show a flickering, disjointed mess – an effect known as ‘tearing’. This effect isn’t as much of an issue now, thanks to advances in software, but the limitation still remains to annoy DBC programmers.


You could just go into your control panel and set VSync to ‘Force Off’, but it’s far better (and easier for users on other computers) to leave it set to the default of ‘Let 3d application decide’ and make some adjustments within DBC itself:

This limitation is due to Windows trying to manage a screen redraw or refresh rate that is the the same or lower than your monitor's refresh rate. The control for this is found in your graphics card settings and is refered to as VSync. Unless you know what you are doing, it's best not to mess with it.

The SYNC RATE in DBC controls how fast your program will run and it's often good to be able to have your program run as fast as possible for whatever reason. Unfortunately, even though the SYNC Rate controls the speed of your DBC program, the 60 FPS limit that applies to the redraw of the monitor, finds it way into limiting the SYNCronization of your DBC game or app. You can remove this cap for yourself and others that you distribute your DBC game or app to with the following:


1) Find and open the file ‘Setup.ini’, located with the file ‘DB.exe’. If you used the default install path, then it should be located in ‘C:\Program Files\Dark Basic Software\Dark Basic’.

2) Read through the file until you find the blitflipmode parameter, and make sure that the line says ‘blitflipmode=1’. This doesn’t do anything by itself, but it allows DBC to give higher frame rates if you do the next step. Don’t forget to save the setup file if you’ve had to make any changes to it.

3) Now you have a choice of what you want to do. You can either:
a) Load an mp3 audio file by calling ‘Load Music ‘myaudio.mp3’, MusicNum’. MusicNum can be any number you like. You don’t even have to play the music, but you’ll notice a sharp increase in frame rate. Note that this won’t work for a midi music file.

b) You could use the following code snippet to create a frame rate increase though using a midi file:



4) When you build your final exe, always place a copy of the Setup.ini file in the same folder as your exe. Without it, the DBC program will default back to locking VSync on, and you’ll still lock at 60fps.

Further Notes
The actual value of 60fps as the maximum program refresh rate will vary from monitor to monitor. Most modern LCD monitors are made to run at 60Hz (that is, they give 60fps), but some 120Hz monitors are around. Also, if you change the display resolution then you may be able to make your monitor refresh faster.

You should also be aware that some computers systems don’t have a frame rate cap – they appear to be ones with older versions of DirectX installed.


Reducing the 100% CPU usage

If you have a CPU meter on your computer, you’ll have probably noticed that whenever you run a Dark Basic program, one core of your CPU is always running at 100%. It is possible to reduce the CPU workload by making the program sleep for a short time each program loop. However, you shouldn’t use the DBC ‘Sleep’ command because this will make text drawn on screen appear to flicker. You have to load the Kernel32.dll, and call the Windows ‘Sleep’ function:



If you can review your CPU meter history after exiting the program, you should find that there will be a sharp peak for the first two or three seconds of running the exe, and after that the program will settle down, using around 40% of the CPU.

Why 40%? It’s because the exe is sleeping for 10ms after every sync, so at 60fps the processor spends 60*10 = 600ms lying idle. So, it must be doing all the work in just 400ms, which is 40% of one second!

With a bit more maths, you can work out how long each frame takes to be drawn to the screen and work backwards to ensure your desired frame rate. It takes 400ms to draw 60 frames, so it’s taking 400/60 = 6.6667ms to draw each frame on screen. For simplicity, let’s call it 7ms. If we want 30fps, then it will take 30*7 = 210ms to draw them on screen. We can let the processor lie idle for the remaining 1000-210 = 790ms, so the sleep period has to be 790/30 = 26.3ms (26 to the nearest integer). Plug in 26 to the above code snippet, and you can see it run at 31 to 32 frames a second.

So, in a nutshell the sleep time calculation is:


You have to be careful about the value you specify for FrameDrawTime – for my computer a value of 7 works well, but this will almost certainly be different for others and I’m not sure it can be calculated at runtime using this method. Because of the 60fps lock (discussed above) a sleep value of anything from 0 to 7 will still produce a constant 60 frames a second. If you read on, you’ll find a neat trick to sidestep it.


Increasing frame rates and freeing up processing power
By combining the above two techniques it is possible to achieve higher frame rates than 60fps, without running one processor at 100%. Try a code snippet like this:


This will return you to a maximum refresh rate of 60fps, but the processor is running at around 12%. There may be frequent processing spikes, but I believe this is due to Windows taking advantage of the fact that your program is ‘Sleeping’ and using the spare processing power for other things.

The sleep time may still be calculated using this formula:


but it now becomes possible to calculate the frame draw time. Call this code at the start of your program:


It works by allowing the program to run at its fastest rate for one second, so we can get access to an accurate Screen FPS() value. By dividing this by 1000 we get the length of time, in ms, the computer needs to draw one image on screen. We can then plug this value into the other formula, and work out how long the program can sleep each sync.

[Note: I wonder about this. IF the the SYNC Rate, or the Monitor FPS that you are talking about? ]

Enjoy your day.
Robert The Robot
17
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 24th Jan 2009 12:32
Hi Latch, thanks for your comments and revisions - your tutorial on "Build Final" is brilliant! I agree with your changes to the "60 fps lock" tutorial, I hadn't thought about it but I suppose for a novice programmer I really shouldn't have suggested they go fiddling around in Control Panel.

For the last part, about reducing the 100% cpu usage, I'm talking about the program refresh rate. For example, when my computer is running as fast as possible I find that Screen FPS() returns a value of about 500. I know the monitor is still only showing 60 of those frames, but if the program is capable of attempting 500 screen updates a second, it must be capable of drawing an image to screen in 2ms (1000/500). We can adjust the sleep time accordingly to give practically any frame rate.

Actually, I've just realised - I made a small typing error in one of those last lines. I say "By dividing this by 1000 we get..." but it should read "By dividing 1000 by this we get..." Oops!

"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 24th Jan 2009 18:07
@RTR
Ok, I understand. Looks like this is starting to shape up a bit.

For Vista, I remember reading something about the D3DRM.DLL being necessary to run DBC. Should that information be included somewhere?

For relative paths, is the format:

load object "\subfolder1\object.x",1 ? I just can't remeber.

Maybe we should include details about the setup.ini file. I'll try putting something together.

What else... Screen Flashing. Is this still a problem with Windows XP and above ? Are there any solutions or work arounds?

Are there security issues when it comes to using DarkEdit - like the paths to read and write stuff need certain permissions? Maybe we should include a general DarkEdit quick setup in the thread... Though I don't know any of the pitfalls in using XP or above with it.

Should we include the midi problem information? Also using mp3s for sound and music instead of midi? The mp3s have to be encoded as MPEG1 layer 3 to work with DBC.

Let's see... No skeletal animations will work. The type of animation that will work is called Hierarchical Animation or Articulated Structure Animation. Is this too small of a detail and shouldn't be included?

Is there any other TECHNICAL information that would prevent someone from running DBC properly, creating an exe, general problems, etc?

Enjoy your day.
Robert The Robot
17
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 25th Jan 2009 20:26 Edited at: 25th Jan 2009 20:32
Quote: "For Vista, I remember reading something about the D3DRM.DLL being necessary to run DBC. Should that information be included somewhere?"

Definitely - and possibly a download of the dll, as an attachment. There have been load's of posts asking about it. DBC needs the dll either in the "c:\windows\system32" folder, or placed in the same folder as the exe. Perhaps that ought to be added to "Getting DBC to run on Vista"?

Quote: "Should we include the midi problem information? Also using mp3s for sound and music instead of midi? The mp3s have to be encoded as MPEG1 layer 3 to work with DBC."

Again, definitely - Dark Basic comes with a host of midi files, and the "cave runner" demo game which is likely to be one of the first programs run also includes a midi soundtrack, whioch makes the program lock for about a second every time it loops around.

Quote: "For relative paths, is the format:
load object "\subfolder1\object.x",1 ?"

You don't actually need the first slash. You can just write the path as "subfolder1\object.x"

Quote: "Are there security issues when it comes to using DarkEdit - like the paths to read and write stuff need certain permissions? Maybe we should include a general DarkEdit quick setup in the thread... Though I don't know any of the pitfalls in using XP or above with it."

Erm... I'm not aware of any issues on XP, but then I'm the only user on my computer and I've no idea how to create a separate account so I can test things. I'd assume that you can only write to the default DBC "myproj" folder if you're logged in as administrator, since that location falls under "Program Files". To be safe, it would probably be best if a new user saved a dba file to their own "My Documents" folder, and then ran DarkEdit from there.

As for reading and writing stuff, something I just stumbled across was that DBC cannot delete a Read Only file. You can call "Delete File", but the file will remain on the computer and won't trigger a warning. Maybe this should be mentioned?


Quote: "What else... Screen Flashing. Is this still a problem with Windows XP and above ? Are there any solutions or work arounds?"

I'm not entirely sure what you mean be "screen flashing". I've heard reference to it before as something that happened on really fast computers (I've a feeling TDK did a tutorial explaining how to get rid of it), but I'm not sure if you mean the flicker/fuzzy mess that you get when you minimise and then restore a DBC application. I've been doing some tests in 2d and 3d, and it appears straightforward to get rid of it.

In a 2d only application, when the user returns to the program you just have to call CLS to reset the screen (or paste image to redraw the background bitmap, depending on the application:



For a 3d only application, it gets more complex:



If the screen is invalid, you have to reset the display mode. This stops the flickering, but erases every image that had been loaded in memory - those used as object textures and those used as sprites. If they were loaded as separate images, then the images still technically exist in DBC but contain nothing that can be pasted on screen. Also, the normnal blue backdrop gets set to white (which is easy enough to correct with "Color Backdrop"). So, the simple solution is to just erase every image that may exist, reload it (or recreate it, if it was generated by the code) and then return yourself to the main program loop. The final repeat loop is just a way of allowing "Screen Invalid()" to start returning 0 again so the whole recreate media routine isn't peformed again. My code snippet above actually shgowes another method, useful for 3d only applications - you can just delete and reload each object that existed.


Concerning the DBC1.20 animation, I think we ought to mention the animation bug we found last summer:


The cube doesn't spin smoothly, but reverses direction during the animation sequence. Maybe we should do a section devoted to 3d animation, explaining the different animation types, which one works in DBC, and how to convert .x files to run correctly. I'll see what I can come up with

"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 28th Jan 2009 18:47 Edited at: 28th Jan 2009 18:50
Wow!! There sure is a lot of information! I've put together some descriptions of the settings in the Setup.ini file. I'm not sure if it should be it's own thread or included in information thread we will create. Also, most of the explanations are guesswork. Please review this an let me know if it seems sound...

Using the Setup.ini File

There is a file in the main DarkBASIC Classic (DBC) installation directory that can influence how DBC behaves in the editor and as a stand alone executable. This file is named Setup.ini. The default path to this directory is usually:
C:\Program Files\Dark Basic Software\Dark Basic

Following is a general explanation of most the settings and their uses.

The items under the heading [SETTINGS] apply to how the default DBC editor as well as the executables that are built using DBC behave. Most settings only apply to the editor. Here are the general descriptions:

[SETTINGS]
TextLanguage=English
TextLanguage-Charset=1
HelpLanguage=English
HelpLanguage-Charset=1

These controls set the language and character set for the default editor's menus, error messages, and help files. In the installation directory, there should be a folder labeled lang. Inside this folder should be subfolders of various languages. Each subfolder should contain a file labeled words. It is this file that holds the translation for the particular language. To set the language for the editor, assign the folder name to TextLanguage and HelpLanguage.

The character set code numbers are listed at the bottom of the Setup.ini file. Assign the appropriate number to TextLanguage-Charset and HelpLanguage-Charset

HelpFontSize=0
This scales the size of the Help text. It's probably best to leave this at 0

ExternalEditor=None
ExternalEditor allows DarkEdit or another text editor to be set as the default editor instead of the DBC black screen with green text editor that opens when you launch DB.exe . It's not necessary to set this control if you start DarkEdit independently. However, if you want to launch DB.exe directly and have it open DarkEDIT, you must have the DarkEdit Folder with all of it's files and subfolders in the same directory as DB.exe. To utilize this function, the line in the Setup.ini should be set to:

ExternalEditor=DarkEDIT156\darkedit.exe

otherwise leave it as:

ExternalEditor=None

The next series of controls have several option settings:
blitoverdraw=0
blitflipmode=1
vbcreate=0
vbusage=0
3doverlay=0
runtimetest=1
tracemode=0
windowmode=0

; Compatabilitiy Settings
; ----------------
; blitoverdraw : 0=normal / 1=Draw All 2D twice
; blitflipmode : 0=double videomem flip / 1=blit to video memory
; vbcreate : 0=normal / 1=WriteOnly / 2=No Clip / 3=[1]+[2] / 4=SystemMem
; vbusage : 0=normal / 1=Wait / 2=WriteOnly and Wait / 3=SurfaceMem and Wait
; 3doverlay : 0=normal / 1=Utilize ZBuffer Clear for overlapped 3D rendering
; windowmode: 0=no window / 1=run in window

; Test and Trace Settings
; ----------------
; runtimetest: 0=simple error reporting / 1=advanced error reporting
; tracemode: 0=no trace information / 1=produce trace files

The Compatability controls allow for adjustments in order to make the DBC display run smoothly depending on the video graphics card. These controls will affect both the editor's and the compiled executable's behavior. Though there isn't any documentation describing what these flags do in depth, I've put together a list of best guesses based on limited knowledge of Windows and DirectX workings and observation from changing the different control values.

blitoverdraw gives you the option of drawing 2d twice. Should you be having problems with 2d graphics showing up improperly when there don't seem to be errors in your program, try changing this value to 1.

blitflipmode
Whenever the screen is blitted, display information is basically copied from one area of memory to the other. If a screen is flipped, a pointer to where the display information is in memory, is changed. Flipping is faster than blitting. In windowed mode, graphics are blitted. In fullscreen mode, graphics buffers are flipped. Sometimes, because of video card drivers and the setup of the graphics card, flipping may cause some display problems with DBC - like slow downs, a disappearing mouse, etc. In these cases, you would set blitflipmode to 1 so that all graphics are blitted through the Windows Graphics Device Interface (GDI). Sometimes when 2d is rendered with 3d, the 2d graphics may flicker or flash. If there are multiple SYNCS called in the program, the 2d portion of the screen that overlaps the 3d portion will be erased and redrawn. If blitflipmode is set to 1, the overlapped portion will flash (because it is being redrawn pixel by pixel); if blitflipmode is set to 0, it will not flash (because the whole image is flipped at once).

The next 2 controls are hard to are not clearly defined. From their names: vbcreate and vbusage, and control settings, one could suppose that they control how the video buffers are managed; those being the actual surfaces that Directx draws on. Following that supposition:

vbcreate is telling DBC where in memory to create it's rendering surfaces and whether or not to create a clipper object. It's probably best to leave this set to 0, normal. If you want to create the surface in system memory as opposed to video memory, use option 4. This may be useful if you have limited video memory; this is probably useful for older systems with older graphics cards. It's hard to guess what option 1 means, WriteOnly. What I would assume is that it means not to create a backbuffer - a second drawing area that is flipped with the front buffer - that all video information is written directly to the screen. Option 2, No Clip suggest that a clipping object would not be created. A clipping object keeps the redrawing of the display within viewable limits. It makes a DirectX application Windows friendly. It's better not to set option 2 or option 3.

vbusage tells DBC how to control the buffer flipping and redrawing. Option 0 means draw according to the blitflipmode settings - swap between the back buffer and front buffer and let directx manage the timing. Option 1, Wait, means don't swap the buffers or update any drawing until the Vertical Blanking Interval (VBI) has passed. In short, don't swap with the back buffer until the monitor has finished drawing it's current frame. This may be a direct control to ensure that your display is never updated faster than what the monitor can redraw. I'm not sure what the difference between option 2, WriteOnly and Wait, and option 3, SurfaceMem and Wait, is. If I were to guess at option 3, I would say it meant draw all graphics immediately to the display without using a back buffer and wait for the VBI until you draw again.

3doverlay=0
Assumingly, this controls how the Z-Buffer behaves. A Z-Buffer helps manage how 3d objects are drawn in front of one another in a scene. In order to be sure that the distance from the camera of each 3d object is as accurate as possible and that objects that are supposed to be in front of another are truly drawn that way, I assume setting this control to 1 will Clear The Z-Buffer every time before multiple 3d objects are displayed to help prevent faces or objects that should be hidden from being rendered and to allow those that are not obscured by other objects or faces, to be rendered.

windowmode=0
Set windowed mode for the default editor. 0 = fullscreen mode; 1 = windowed mode

runtimetest=1
tracemode=0

The Test and Trace settings control error message output and whether or not a trace file is created. If a trace file is created, it will reside in the main directory with the title Db.dba. If you open it with Wordpad or Word, it will list the DBC source that was just run. The DB.log file will contain a list of the initialization of the DBC interpreter and game engine.

popupoff=0
This controls whether or not there is a display that shows the enhancement pack availability and installation when DBC is launched from the editor. Setting it to 1 will turn this display off. I leave it set to zero just because I don't see the words DARKBASIC v 1.14 ENHANCED at the bottom if I set this to 1. I don't think it turns off the enhancements, but I don't want to tempt it!

The StartUP Settings list the settings that will directly affect the application or game you create as an exe when you distribute the Setup.ini file with your built program.

; StartUp Settings
; ----------------
; Use a SETUP.INI file with the [STARTUP] keys below to
; control the initial state of your application:-
; eg. window=1 will start your app in a window

[STARTUP]
window=0
winposx=0
winposy=0
winsizex=640
winsizey=480

The CharSet Codes are the codes to be used with TextLanguage-Charset, and HelpLanguage-Charset at the top of the ini file. These codes are also used with the SET TEXT FONT command when coding in DBC:
ex. SET TEXT FONT "MS HEI",136

; CharSet Codes
; -------------
; DEFAULT_CHARSET 1
; SYMBOL_CHARSET 2
; SHIFTJIS_CHARSET 128
; HANGEUL_CHARSET 129
; HANGUL_CHARSET 129
; GB2312_CHARSET 134
; CHINESEBIG5_CHARSET 136
; OEM_CHARSET 255
; JOHAB_CHARSET 130
; HEBREW_CHARSET 177
; ARABIC_CHARSET 178
; GREEK_CHARSET 161
; TURKISH_CHARSET 162
; VIETNAMESE_CHARSET 163
; THAI_CHARSET 222
; EASTEUROPE_CHARSET 238
; RUSSIAN_CHARSET 204
; MAC_CHARSET 77
; BALTIC_CHARSET 186

Enjoy your day.
Ashingda 27
16
Years of Service
User Offline
Joined: 15th Feb 2008
Location:
Posted: 28th Jan 2009 19:17 Edited at: 17th Mar 2013 21:18
Another note, some people may not have this file and I'm not sure why. When I checked for mines it didn't exist in the folder specified so I copied in the one downloaded from Robert the Robot.

Attachments

Login to view attachments
Robert The Robot
17
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 2nd Feb 2009 10:44
Hi Latch, sorry I've been a few days replying but I ran into some trouble with the animation bug tutorial. I've been struggling to simulate it again, but I'm now faced with all existing .x files playing correctly when loaded in DBC 1.20, while those with animation sequences generated by DBC1.20 will fail.

I'm not sure quite why this should be - I certainly don't remember getting this before. I'd be grateful if you could verify this, so I've attached two objects in a zip file. One is called "H-Alien Mutant-Attack1.x", taken straight from Dark Matter. The other is "Test alien.x", which was produced by Lightning Limbs (my program looked at the keyframe data, set the keyframes using DBC's internal animation commands, and then exported the reuslt as this final .x file). I find that the first file plays smoothly, but the second file has a sharp reversal partway through the animation.

If this does prove to be the case, then I'll rewrite the animation tutorial I'd prepared so that it only referes to the internal command set.


By the way, that explanation of the setup.ini file seems fantastic

"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."

Attachments

Login to view attachments
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 4th Feb 2009 20:01
Quote: "but I'm now faced with all existing .x files playing correctly when loaded in DBC 1.20, while those with animation sequences generated by DBC1.20 will fail.

I'm not sure quite why this should be - I certainly don't remember getting this before. I'd be grateful if you could verify this,"


The situation was that there was a discrepancy in the way animations created in DBC 1.13 and animations created in DBC 1.20 did not behave the same in DBC 1.20 . DBC 1.20 has the 120 degree rotation reversal problem for any animations created in DBC. This became evident when trying to create an animation program written in DBC. To correct the problem, the goal was to create a 'proper' quaternion that could be interpreted correctly by both DBC 1.13 and DBC 1.20 . Most 3d Modeling software already create the correct quaternions that define the rotations in + or - directions. That is why animations created in a modeling program will perform correctly in most cases in DBC 1.20 and DBC 1.13. Thus the DarkMATTER models should function fine. Your animation program, Lightning Limbs, should also account for this if you built the conversion routine you wrote into it.

I think our concensus was that because rotations in DBC are from 0 to 360, and the value tends to always be wrapped when using commands such as ROTATE OBJECT, ROTATE LIMB, etc. the limit is within 0 to 360 positive euler angles and cannot be identified in the opposite direction with a -. Internal calculations in DBC 1.13 check the difference of the rotation from the previous interpolated frame to the current frame and if it is less than 180, the rotation was in the + direction. If the difference was greater than 180, the rotation would be in the - direction. DBC 1.20 did not seem to have this check and always reversed the angle after 119 degrees no matter what the difference between interpolated angles (maybe someone typed in the version number for the check instead of 180! ). We also discussed the removal of the dependency of D3DRM in DBC 1.20 . I wrote example functions that showed it was likely that the rotation calculations in DBC 1.13 were based on using the DLL functions directly out of D3DRM. Using the same functions, I was able to reproduce the same results in DBC 1.20 . But the new DBC 1.20 on it's own, doesn't seem to use these functions internally.

In short, the rotation error occurs when animations are created within DBC 1.13 or 1.20 and run in 1.20. DBC 1.13 will play all of them fine.

Enjoy your day.
Robert The Robot
17
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 5th Feb 2009 21:26 Edited at: 5th Feb 2009 21:32
Thanks for the info Latch. Here's my Tutorial on 3d animation - hope you like it!

Dark Basic and 3d Animation
There are two types of 3d animation called Skeletal Animation and Hierarchical Animation (it is also known as Articulated Structure Animation, but often just referred to as limb based animation). In Skeletal Animation, each polygon in the 3d model is assigned to an internal and invisible ‘bone’. When these bones are rotated, they adjust the polygons assigned to them so that they move into a new position. However, it should be noted that DBC cannot play this type of animation at all (if you require this kind of animation, you’ll have to switch to DBPro).

In Hierarchical Animation, the 3d object consists of a series of small, separate meshes known as limbs. For example, in a 3d model of a human there is one mesh for the head, one for the neck, another for the torso and so on. These limbs are then linked in sequence by a parent-child hierarchy so that any program playing the animation can automatically work out which limbs should be affected by the rotation of a particular limb, and adjust all the others accordingly. This is the only type of animation that DBC can play.

Problems with limb-based animations in DBC v1.20
There is an error in DBC v1.20 that affects some limb-based animations loaded from .x or .3ds files, and some animations generated at runtime from your code. This example illustrates the problem:



You would expect to see a cube that spins round from 0 to 360, but if you watch carefully then you’ll see it spin, reverse direction for a time and then reverse direction again to complete the animation. Careful experimentation has shown that when the rotating limb tries to pass through 120 degrees on any axis, it will reverse direction and move ‘the long way’ through 90..0..270..180..120 and then reverse direction again to continue the animation as expected.

So what’s going on? The problem lies with the behind-the-scenes conversion of Euler angles (the 0 to 360 degree angles that you specified) into slightly more useful quaternions. Quaternions use four numbers to define a rotation – three define a vector that is the axis of rotation, while the fourth defines how far to rotate about this axis. When playing an animation, DBC uses a method called quaternion slerping to move each limb along the shortest route from the quaternion in one keyframe to the quaternion in the next keyframe. DBC miscalculates this shortest route and so when a rotation about an axis hits what is 120 degrees in normal angles, it thinks that the shortest route to travel across 119..120..121 is to go 119..90..0..270..180..120.

This whole problem will not arise if the quaternions used in the animation were generated from Euler angles in the range -180 to 180 (angles greater than 180 are wrapped around to become negative, so 181 becomes -179). Many professional animation packages appear to handle this automatically, which is why the DarkMatter models will always play correctly.

Sometimes, however, the quaternions were generated from Euler angles in the range 0 to 360 in which case a fully functional quaternion slerping routine is vital for correct playback. If you find a 3d animation that does not play correctly, you can use the program in the attached zip file to create a copy of the .x file with recalculated quaternions that will play correctly. The process converts each quaternion into a set of Euler angles, wraps them into the range -180 to 180 and then creates a new quaternion. You should note that this will not affect how the object plays in other computer programs

Since Euler angles in DBC are always in the range 0 to 360, any animation data you generate using DBC’s ‘Set Object Keyframe’ commands will suffer the same problem. You must either restrict your animation so that it never attempts to cross the 120 degree mark on any axis, or use the following procedure. You’ll need the QuatMath dll in the attached Zip, which will have to be distributed with your exe:



Note the commands at line 154 – these allow you to reload the animation data to your 3d object. You must specify a value for ObjNum, which is the number of the object whose animation is to be updated. Also, be aware that the code will crash if files 1 and 2 are already in use.

Final Notes
One curious feature of the error in DBC v1.20 is that there is now nothing to stop you from specifying angles between -360 and 360 and using the resulting quaternions in your animation. You can now choose whether to make the limb move the short way round (using an angle between -180 and 180) or the long way round (using an angle between -360..-180 or 180..360). You can even specify still larger angles, forcing the limb to make multiple revolutions between two keyframes. However, no matter what quaternions are specified the limbs will always move the shortest possible route in all programs – except for DBC v1.20.

"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."

Attachments

Login to view attachments
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 5th Feb 2009 23:09
This is excellent! You're very clear in your explanations!

I do have a question though,

Quote: "One curious feature of the error in DBC v1.20 is that there is now nothing to stop you from specifying angles between -360 and 360 and using the resulting quaternions in your animation"


Does this mean that without using your conversion program, you can rotate the limbs in any direction even using negetive numbers? I think -numbers return the Specified angle must be 0 to 360 degrees error.

Enjoy your day.
Robert The Robot
17
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 7th Feb 2009 20:34 Edited at: 7th Feb 2009 20:35
Sorry about that, Latch, you're right in saying that DBC only allows angles between 0 and 360. I should have explained it better - if you generate a quaternion animation file using the QuatMath dll, and not DBC's native commands, then you can inout angles of any size and the resulting quaternions will allow multiple rotations between two keyframes in DBC v1.20 only.

I'll edit that bit later, in the meantime I'll see if I can get something together to explain the midi problems some time tomorrow. With luck I'll be ready to post it on Monday!

"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 8th Feb 2009 01:45
Sounds good!

in regards to D3DRM.DLL
Quote: "Definitely - and possibly a download of the dll, as an attachment. There have been load's of posts asking about it. DBC needs the dll either in the "c:\windows\system32" folder, or placed in the same folder as the exe. Perhaps that ought to be added to "Getting DBC to run on Vista"?"


Yeah. It should be included under that section.

Enjoy your day.
Robert The Robot
17
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 9th Feb 2009 20:03 Edited at: 9th Feb 2009 20:04
Ok, here's what I knocked up concerningDBC and music. Hope it's good!

Music in DBC
DBC v1.20 has some problems when it comes to playing Midi music files – while it can load and play the music without a hitch, it cannot easily loop the music round for repeated music. If the ‘Loop Music’ command is called, when the midi track comes to an end and has to be restarted it will make the whole program freeze for up to a couple of seconds.

If you know the length of the audio track, then it is possible to use ‘Stop Music’ and ‘Play Music’ at the right moment to restart the audio track and make it play forever. There is a very slight pause while doing this, but this shouldn’t pose a problem.

One much better method is to convert your Midi files to mp3 audio files. Midi files are tiny because they store no audio data at all – instead, they are just a list of which notes to play, how long to play each one for, and which musical instrument is to play them. When playing a midi file, your computer uses its sound card (which has sound effects for 128 musical instruments hardwired into it) to produce something your speakers can play for you to hear. Unfortunately, these hardwired sound effects are notoriously poor quality and can vary considerably from computer to computer. Mp3’s, on the other hand, are much better because in spite of their much larger size they can give you CD quality audio.

So how do you convert a low quality midi to a high quality mp3? You need to use a program like SynthFont, which takes a midi file and plays it using soundfonts instead of the sound cards hardwired audio effects. These soundfonts contain audio files of the various notes that a musical instrument is capable of playing, and can make a midi sound like it was being played by a full orchestra in a professional recording studio!

Many high quality soundfonts are available for free, but be warned that the best will be quite large files to download. You should also note that the midi to mp3 audio conversion requires a considerable amount of computer RAM (at least 500Mb) if you expect to hear the output in realtime. The mp3 files that SynthFont creates can be very large so you may wish to use another program to load and re-save the music track as an mp3. Finally when using ‘Loop Music’ with mp3’s there is still a pause as the audio track loops round but this is barely perceptible.

Music in older versions of DBC
DBC v1.13 has a more fundamental problem since it cannot load midi files at all. It is possible to make it play a midi by calling the windows multimedia dll directly, and bypassing the effectively useless music commands in DBC v1.13, using this code:



However, you can use the music commands with mp3 files and they will work perfectly. See the above section for information on converting existing midi files to mp3 files.

"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 11th Feb 2009 20:46
Looks good RTR. I didn't realize SynthFont used so much overhead! Though I do remember favoring Timidity++ over it because SynthFont was a bit clunky. Timidity++ is a bit more streamlined and can be run even on a 386 or 486 processor... Though, I'm one for tinkering and don't mind playing with configuration files and command land parameters (which can be required for timidity++). I've gone off on a tangent!

Sorry I haven't posted for a while. This thread has a lot of information and obviously, you've put in a great deal of time and effort! I think that's great! Thank you!

In this:
Quote: "Music in older versions of DBC
DBC v1.13 has a more fundamental problem since it cannot load midi files at all. It is possible to make it play a midi by calling the windows multimedia dll directly, and bypassing the effectively useless music commands in DBC v1.13, using this code:"


On my machine, in any version of DBC, midi, sound, everything plays fine, though I do not have that one update of DBC 1.13 2006? that was a bit of a disater and prompted the release of 1.20, I think that's when the real complaints about midi not playing and TDK mentioned not being able to DO ANYTHING about his screen flashing. I suggest rewording that part a bit like this:

In some cases, midi files will not play at all using the Music commands in DBC. However, it is still possible to play a midi file by calling the windows multimedia dll directly. etc.

Perhaps at the top of the final thread, we should just have bullet points for each subject that tells the quick and dirty way of getting things working. Further down in the thread can be the full on explanations. What do you think?

Enjoy your day.
Robert The Robot
17
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 14th Feb 2009 11:45
Hi Latch! I haven't tried Timidity, but I'm having brilliant fun with SynthFont - I've spent quite a bit of time tracking down different sound fonts to use with it, and the computer is starting to sound like a full orchestra .

I'm not too sure which updates to DBC there have been - it gets confusing because of the enhancments patch. It drove me a little crazy at first, actually, because when I upgraded to XP a year or so back, I ran DBC with the 1.13 EP 30 day demo and everything worked fine until the demo expired. Even once I'd bought and installed the EP, Load Music would never work with midis until I got hold of V1.20.

Anyway, I've been going through all the different tutorials that have been posted, and compiling them into a single word document. I've taken into account the different changes and suggestions that you've made, and also added a set of three quickfire questions at the start - I couldn't think of any others to add! It's quite a lot of stuff we've written, it runs to 17 pages with all the code snippets expanded!

"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."

Attachments

Login to view attachments
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 14th Feb 2009 22:06 Edited at: 15th Feb 2009 09:10
Looks good. BIG!!

I'm gonna go through the document and see if I can shorten it up. Probably be a few days.

Enjoy your day.
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 23rd Feb 2009 12:53
@RTR
Sorry I haven't posted on this in a while. I'm totally losing motivation to work on it any more.

I think it's generally ready to go. I guess a short list could be worked out at any time and just addended to the top of the post.

For a title, we want searches to hit on words like install, setup, vista, getting started , basics, - I dunno. Can you think of any other relavent title hits?

So, perhaps the format of the post would be:

Introduction:
This is a reference to get you started using DarkBASIC Classic (DBC).. blah blah blah

Body:
Detailed documentation is contained (in the attachment? ) but for a quick start check out Quick Points.

Quick points: (if any)
* Make sure d3drm.dll exists on your computer and is located in the c:\windows\system32 folder for windows versions greater than ME and c:\windows\system for version ME/98/95 .

* Copy this Setup.ini file into the same directory where DB.exe lives. This is usually located at <path> . Refer to the documentation on the Setup.ini for information on the various parameters.

* Distribute a (modified) copy of the Setup.ini file with your executables

* Before using DarkEDIT, an alternative and more Windows friendly programming editor, after installing it, make sure you click on Edit > Edit Options > DarkBASIC Options and fill in all of the necessary paths and locations.

* Make sure any media you want to include in your program is kept in the same folder or in subfolders where your program is stored.

* CPU resources maxed out at 100% - see documentation

* "I can't change the 60 FPS cap" - see documentation

* "My midi music files won't play or won't play correctly" - use mp3s instead and/or see documentation for alternatives

* "My Animations don't work." - DBC can only import models in Direct X (.x) or .3ds format. DBC cannot use skeletal animation (bones/skinning). It uses linked limbs in a hierarchical parent-child structure.

* Check out the following links to help get you started programming with DarkBASIC Classic and hopfully to answer some common questions:

TDKs Tutorials
DarkBASIC Tutorials
a) Monster Hunt
b) Binary Moon
Upgrades
DBC 1.20 Commands Explained
Resource Links for New Comers
DarkBASIC Animator - Lightning Limbs

Enjoy your day.
Robert The Robot
17
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 24th Feb 2009 21:58
Quote: "Sorry I haven't posted on this in a while. I'm totally losing motivation to work on it any more. "

Don't worry, I haven't even thought about this the last week! (things have been getting a little hectic, I'm not even getting any time for coding )

How about a title like:
install, setup, vista, getting started, basics, frame rate, 100% CPU, music, animation.

I like you're layout for the post - I had thought of just collating everything in the word document as a temporary reference, but I think you're right to make it an attachment and have just quickfire answers to questions in the main post.

I'll put together the finishing touches in a day or two (might not post until the weekend, but I'll see what I can do) and post them here for a final check before we launch the main tutorial thread.

"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 24th Feb 2009 22:35 Edited at: 25th Feb 2009 21:44
I'm a little on the fence about the attachment in terms of detailed info. It does make sense and people could have it as a reference document without having to go online - I just see the laziness factor creeping in where people want answers immediately! I suppose that's where the quick list comes in... Am I over thinking???? The more I think about it, the more I like it. With a little work and conversion, it could be an html document that is accessed from the help. I'll take a quick stab at that before you get in too deep...

Watch this post before you do the final.

Possible Title:
Getting Started with DarkBASIC - Install, Setup.ini, Vista, D3DRM.DLL, Frame Rate - fps, 100% CPU, Music (midi), Sound, Animation

I changed setup to setup.ini because that should flag a hit in either case if someone searches for Setup or setup.ini

And I forgot a very important bullet point: RTFM !
or perhaps a little more diplomatic: Make sure you go through the help files that come with DarkBASIC. Most questions relating to the DarkBASIC language are covered in there.

[EDIT]
Well, I made the document into an html file. In order to get it to link to the help system, a couple other of the help htmls have to be modified. Then those new ones would have to be distributed and users would have to put them in the correct folders... and if they copy or delete something they could screw up their help system... So I'm gonna abandon the idea of making it into an addition for the DBC help.

Enjoy your day.
Robert The Robot
17
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 28th Feb 2009 11:29
Ah, OK. I'll finish of the tutorial guide and then post it up here later today. I've been a bit snowed under with work the last few days, and haven't had a chamce to work on it much, but it's almost finished.

"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 2nd Mar 2009 00:25
I reread my previous post. It sounded like I was telling you to RTFM. That's not what I meant (in case that's how you read it!) I meant that that should be one of the bullet points to be included in the quick list.

Enjoy your day.
Robert The Robot
17
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 4th Mar 2009 13:35 Edited at: 4th Mar 2009 13:36
Don't worry Latch, I knew that was what you meant! I've been working on a proper introduction (based mostly on what you wrote, actually) and this is what I've got. I've also modified the word document a little as well, taking out some of my "Quickfire questions" because you'd covered the stuff much more succinctly.

Getting Started with DarkBASIC - Install, Setup.ini, Vista, D3DRM.DLL, Frame Rate - fps, 100% CPU, Music (midi), Sound, Animation

This is a reference guide designed to get you started using DarkBASIC Classic (DBC), which should answer most of your initial questions. Vista compatibility, building your games for distribution, using DarkEdit, reducing the 100% CPU usage - all the basics are covered here.

Detailed documentation is contained in the attachment but since it runs to 17 pages, here’s a quick and simple overview of everything it contains:

Quick points:
* Make sure d3drm.dll exists on your computer and is located in the c:windowssystem32 folder for windows versions greater than ME and c:windowssystem for version ME/98/95.
If the d3drm.dll is not there, then you can find it in the zip file attached to this post.

* Copy this Setup.ini file into the same directory where DB.exe lives. This is usually located at <path> . Refer to the documentation on the Setup.ini for information on the various parameters.

* Distribute a (modified) copy of the Setup.ini file with your executables

* Before using DarkEDIT, an alternative and more Windows friendly programming editor, after installing it, make sure you click on Edit > Edit Options > DarkBASIC Options and fill in all of the necessary paths and locations.

* Make sure any media you want to include in your program is kept in the same folder or in subfolders where your program is stored.

* CPU resources maxed out at 100% - see documentation

* "I can't change the 60 FPS cap" - see documentation

* "My midi music files won't play or won't play correctly" - use mp3s instead and/or see documentation for alternatives

* "My Animations don't work." - DBC can only import models in Direct X (.x) or .3ds format. DBC cannot use skeletal animation (bones/skinning). It uses linked limbs in a hierarchical parent-child structure.

* Check out the following links to help get you started programming with DarkBASIC Classic and hopfully to answer some common questions:
(we'll have to add in the various links you posted earlier)

* "I can’t load an Object/Image – it keeps saying the file could not be loaded"
1) Check that you typed the file name properly, and remember to include the three or four letter file extension.
2) Check the file path you have specified. DBC starts by looking in the same folder as the the .dba source code being run, and working from there. Imagine you have this folder to contain you source code – “C:/Program Files/my proj” – and this folder to contain all you 3d objects - “C:/Program Files/my proj/Objects”.

If you call ‘Load Object “Knight.x”, 1’ then DBC will look for the file in the “my proj” folder, but won’t find the file since it is actually in the “Objects folder”. To successfully load the file, call ‘Load Object “Objects/Knight.x”, 1’

You should always specify paths relative to the folder you are currently working in (which can easily be found by calling the command “Get Dir$()”)

* "DBC gave the error ‘Music could not be loaded at line …’ "
In certain older versions of DBC, this can happen if you try and load a midi music file. This can easily be fixed by downloading and installing DBC v1.20 (which should be available via your Order History) An alternative solution is to convert your midi files to mp3 audio files – full details are given below under ‘Music in DBC’.

* Don't forget to read the help files! Aside from the detailed documentation on each command, DBC comes with dozens of example programs to show how particular commands work and they're well worth looking at. You may well find that they already answer your question!

* And Lastly, don't forget to have fun programming!

"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."

Attachments

Login to view attachments
Quirkyjim
15
Years of Service
User Offline
Joined: 18th Oct 2008
Location: At my computer
Posted: 4th Mar 2009 23:13
Can DBC load .3ds? I thought that it was just .x

~QJ
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 11th Mar 2009 05:43 Edited at: 11th Mar 2009 05:57
@QuirkyJim
DBC can handle both X and 3DS. DBPRO cannot handle 3DS any longer.

@Robert The Robot

Here's an addition (in italics) to the intro:

This is a reference guide designed to get you started using DarkBASIC Classic (DBC), which should answer most of your initial questions. Vista compatibility, building your games for distribution, using DarkEdit, reducing the 100% CPU usage - all the basics are covered here.

As DBC was designed for older Windows operating systems, it's performance can vary from machine to machine. This guide came about in recognition of some performance failings that have come about as Windows has advanced and has been redesigned and DBC has not. Included in this reference is not only optimizing CPU usage, managing the speed at which DBC runs, and your distributal games and applications run beyond the recent occurance of a 60 FPS limit, but addressing media failings in terms of animation, midi, music, and sound performance.

Besides a couple of typos on my part here and there, this looks ready to go. Do you want to do the honors, or do you want me to?

Enjoy your day.
Robert The Robot
17
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 20th Mar 2009 12:13
Hi Latch, sorry it's taken me over a week to post back, but I've been a bit snowed under with work (not to mention I bought Evochron Legends and just couldn't stop playing... )

I like the intro revision you've suggested, it works a lot better than my one. If you'd care to do the honours and post the final version, I'd be grateful.

I probably won't be around on the forums much for about the next fortnight, but I'm hoping to get some time to spend coding pretty soon - I'm hoping to get back to work on DarkWindows, it's in pieces at the moment but a complete rebuild from the ground up should make things easier.

"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."

Login to post a reply

Server time is: 2024-03-29 15:44:54
Your offset time is: 2024-03-29 15:44:54