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 / Recent Machines Too Fast For DBC?

Author
Message
TDK
Retired Moderator
23
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 10th Jul 2007 05:29
Link
After a spate of problems running DBC and the notorious 'flashing screen' problem I was beginning to suspect that my machine was simply too fast for DBC.

Tonight, while working on my 2D Scroller Editor I had a problem when my program created an array of all the uniquely used tiles in a level.

My routine simply scanned the tile image numbers used in a level and added them to the array - only if that number was not already there.

But it just didn't work. As a test, I used the following code in the section which placed the image numbers in the array:



The strange thing is that the correct values were printed out for TilesUsed and CurrentTile but it always printed 0 (zero) as the contents of NumUsedTiles(TilesUsed) - not the same as CurrentTile as it should have done.

I knew the code was correct, but after a considerable amount of hair pulling, I tracked down the problem...

When a level is loaded, I need to clear out the old contents of the array so I use:



And therein lies the problem. It seems that my machine runs so fast, DBC hasn't finished doing the Undim before the Dim line is reached and it was getting skipped. My array was being deleted but not created again!

So, to confirm this, I used:



...and the program started working perfectly. It seems that the faster your machine runs, the bigger the Wait you have to insert.

Having thought I'd stumbled across the possible reason for all my flashing screen problems, I went back and added a Wait 100 to the end of the Sync lines and hey presto - no more flashing screens since.

Now, the question is how many other commands are there in DBC that we don't know about take so long that they too need a Wait placing after them?

TDK_Man

* TDK's Game Programming Forums - Open To All - DB & Team Request Boards *

Back to top
Profile PM Email Website
Latch
19
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 10th Jul 2007 09:38
Link
TDK,

In the DIM problem, if you were going to reuse the array, would using a loop and zeroing out the values be faster that pausing for 100 millisecs? Assumingly, one's machine with a faster processor should process the loop pretty fast. The question is, would it be faster than the Wait command?

And since arrays declared in functions are local, could you use a function that holds a local array, perform the caluclations with the array that you need to redimension, then on exit, the array is destroyed?

Enjoy your day.
Back to top
Profile PM
TDK
Retired Moderator
23
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 10th Jul 2007 10:02
Link
The actual time it takes to do the UnDim and Dim isn't time intensive, (as far as the program is concerned), so the Wait 100 doesn't really matter. It's only being done when the level initializes so the tenth of a second wait isn't even noticed.

I didn't use a For..Next loop to clear the array because the next stage was to reDimension it to the required size for the level being loaded. The array was not always going to have 512 elements - it just did at the time.

More to the point, it seems that there could be a few commands in our DBC programs that aren't getting executed when running on a fast machine - or so it seems...

TDK_Man

* TDK's Game Programming Forums - Open To All - DB & Team Request Boards *

Back to top
Profile PM Email Website
Latch
19
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 10th Jul 2007 10:35
Link
Well, I've had to stick a wait 50 in from time to time when using

MAKE MEMBLOCK FROM IMAGE
or
MAKE MEMBLOCK FROM MESH

because the resulting mesh or image inside the memblock wouldn't be available, unless I put that pause in.

DBC seems to be a bit slow when it comes to the allocation and deallocation of memory (which an array falls directly in catagory with). I have an older computer AMD 1.5 ghz and run DBC on windows 98 so I haven't seen any of the flashing. The only thing I've noticed are the memblocks not keeping up.

Enjoy your day.
Back to top
Profile PM
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 10th Jul 2007 17:44 Edited at: 10th Jul 2007 17:49
Link
So TDK, I see that you have read my analysis of the screen flashing,
http://forum.thegamecreators.com/?m=forum_view&t=109529&b=10
and have you extrapolated from it.

However your extension of my explanation for the screen flashing
(the graphics pipeline not keeping up with the code execution), does not make sense if the reason is faster CPUs.

If the processor is faster,
then the commands like Make Memblock From and Undim ,
would work faster,
not slower!

Therefore, having to make DarkBASIC programs wait for commands to finish so it can properly execute subsequent commands,
has to be for a reason other than fast processors.

The answer to your topic question is no.

I'm unique, just like everybody else.
Back to top
Profile PM Website
TDK
Retired Moderator
23
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 10th Jul 2007 22:52 Edited at: 10th Jul 2007 22:52
Link
Quote: "Therefore, having to make DarkBASIC programs wait for commands to finish so it can properly execute subsequent commands,
has to be for a reason other than fast processors."


Hence the reason for my other post - to try and find some link between machines experiencing the effect.

The flashing, the memblock problem LBFN describes, my Dim proble - all seem to require a Wait inserted or they don't work.

Quote: "So TDK, I see that you have read my analysis of the screen flashing, http://forum.thegamecreators.com/?m=forum_view&t=109529&b=10
and have you extrapolated from it."


Not really - I've been using Sync as a pause since I started using DBC on XP a long time ago so I was aware of the required delay to stop the flashing.

The problem just came back a short while ago - even with all my previously working source code. It just hadn't occurred to me that this might be down to me now having a faster machine than back when they were first written and might need a longer pause than the Sync I was using.

Quote: "The answer to your topic question is no."


Well if someone else runs a piece of code that flashes on my machine on theirs - a slower machine but also with XP - and it doesn't flash then logically it must be down to the speed of the machine.

If I add Wait commands to the code and it stops flashing on my machine then that surely enforces the notion that it's a speed (or at least timing) problem.

So I'm still inclined to believe that the answer is 'yes'!

TDK_Man

* TDK's Game Programming Forums - Open To All - DB & Team Request Boards *

Back to top
Profile PM Email Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 11th Jul 2007 03:02
Link
TDK, to your question "Recent Machines Too Fast For DBC?" the answer is no, since I use it every day on my new 3 GHZ XP Pro Intel machine.
In recent years the machines have been gradually getting quicker, but nothing has broken DBC yet.

We both know how long that we've been fixing the flashing, as we've both been on the DB board for years.

Since no one else ever has, I recently gave my detailed WHY it is happening analysis in response to LBFNs request.

The problem that YOU are having is that your Sync solution is not a fixed commodity when it comes to timing, whereas Wait is.

I think that the solution of Wait 2 to fix the flashing will not break in the future.

I'm unique, just like everybody else.
Back to top
Profile PM Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 11th Jul 2007 03:06
Link
The problems of non graphics commands like Make Memblock From and Undim not finishing before the next command starts executing is another thing entirely.

That behavior I have no clue about and it sounds nasty. It may be justification for real concern if the problem has no workaround.

However once the problem is exposed and documented and it has a workaround,
then it is simply another of the many restrictions placed on us as programmers that we must compensate for.

So the answer remains, NO.

I'm unique, just like everybody else.
Back to top
Profile PM Website
Hangar18
19
Years of Service
User Offline
Joined: 13th Mar 2007
Location:
Posted: 12th Jul 2007 01:34
Link
This could be a disaster. Its hard enough trying to debug problems in DB without worrying about the speed of the machine. TDK, one thing though, I didnt think an undim command was necessary if you were going to 'Dim' it again. I thought that once DB reads a Dim command it automatically resets everything to zero. ie.

Dim Array(3,4)
Array(1,1) = 3
Array(1,2) = 6
Dim Array(5,7)

Shouldnt this dim command now set Array(1,1) to zero?
Back to top
Profile PM Email
TDK
Retired Moderator
23
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 13th Jul 2007 03:27
Link
Quote: "Shouldnt this dim command now set Array(1,1) to zero?"


It shouldn't but it does!

I've never even looked at Dim and UnDim in the help files because I've used the commands for many, many years and they've always worked the same... up until now!

You should get a dimensioning error if you try to Dim the same array twice - if you haven't used UnDim. But with DB apparently you don't.

Very strange...

What does the following snippet print for you?



Mine prints 0.

TDK_Man

* TDK's Game Programming Forums - Open To All - DB & Team Request Boards *

Back to top
Profile PM Email Website
Latch
19
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 13th Jul 2007 06:53
Link
@tdk

it prints zero when the Undim and Dim are on the same line, but 100 when they each have their own line.



Maybe the Basic interpreter behaves the same way with UnDim as it would with:



Maybe once the condition of undim is set (treating Array() as false because it has been deallocated), the program counter moves on to the next line.

Enjoy your day.
Back to top
Profile PM
Hangar18
19
Years of Service
User Offline
Joined: 13th Mar 2007
Location:
Posted: 16th Jul 2007 07:28
Link
@Latch, ah thats interesting and makes sense in light of an unexpected result I had with DB in a similar vain. If you type,

If X=1 then Y=2
T=5

Then T=5 in all circumstances. BUT if you type....

If X=1 then Y=2:T=5

Then T=5 only if X=1, the : which I thought was supposed to be equivalent to a new line, is in fact conditioned on the if statement. Just while we're on the top of strange DB outcomes, I foudn to my frustration that typing...

Cash#=OldCash#-Trade#+Cargo#

really equates to:

Cash#=OldCash#-(Trade#+Cargo#)

i.e. DB takes off cargo# instead of adding it!!
Back to top
Profile PM Email
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 16th Jul 2007 08:39
Link
Quote: "If you type,

If X=1 then Y=2
T=5

Then T=5 in all circumstances. BUT if you type....

If X=1 then Y=2:T=5

Then T=5 only if X=1, "

That is the documented behavior and is correct.

Quote: "Cash#=OldCash#-Trade#+Cargo#

really equates to:

Cash#=OldCash#-(Trade#+Cargo#)

i.e. DB takes off cargo# instead of adding it!!"


You found that nasty parsing bug of DarkBASIC.
As you undoubetly have figured out you'd have to use the parenthesis like this:
Cash#=(OldCash#-Trade#)+Cargo#
to get the compiler to produce the correct code.

I'm unique, just like everybody else.
Back to top
Profile PM Website
Back to top

Login to post a reply

Server time is: 2026-07-06 06:43:55
Your offset time is: 2026-07-06 06:43:55