BlitzMax Slow? [BMAX]

[valis]

Some of the opinions on this forum seem to indicate that BlitzMax is slow.

I've run into this a little bit myself, but that was when I was newer to the language and was trying to use the 2d graphics library to display many hundreds of software-rotated objects.

Is it generally the case that it's slow, or does the slowness mainly show up at the extreme high end of things you might want to do, like write realtime software raytracers and that sort of thing?

I must admit that I love Max but I could just as easily move to something else like C++ with SFML or some other media library.  Or perhaps even Ogre...

[Jim]

These BASIC languages aren't really made for speed, so number crunching for raytracing and the like is going to suck.  But they're not bad and you can easily do 640x480 pixel-wise fx without problems.
If you want the speed, you're going to need to use C.

Jim

[valis]

That's fine with me really since I know C as well, I'm just very enamored of BlitzMax for some reason.  Maybe I will go back to C/C++ now and some of the BlitzMax idioms will follow me there.

I think now is the time to start working on realtime raytracing engines.  Processing power for that stuff is going to arrive in about 2 years.

Another thing I've noticed is that regardless of platform (linux or windows 7) there is hitching in BlitzMax every few seconds.  I've seen this discussed elsewhere but no solution was offered.  By this I mean inexplicable slowdown every few seconds for perhaps a 1/10th of a second or less.

What's going on here?  Anyone know?  It seems to happen regardless of what program is running at the time and seems to happen in both debug and release builds.

[zawran]

You could use BlitzMax and then just have the number chrunching code done in C. BlitzMax is fully capable of interfacing with C code. A lot of BlitzMax itself is written in C. Have a browse through the code of BlitzMax which is fully available to you, and perhaps check out the blitzmax website where there are plenty examples of how adding C code to your BlitzMax code is done. Since BlitzMax is more or less written in C, it is not really much slower than C, but certain parts of the language might not be as optimised as it could be with code wrtitten for one specific purpose, so for certain things it might be better with pure C code. Probably one of the reasons a lot of the code behind the BlitzMax language is written in C.

I have not really noticed the hitching that you mention, but it might be something with the way you code your main loop in your programs. You have to leave a little bit of time for the system to let it do its thing. It could also have something to do with garbage collection, which the language comes with standard. Perhaps you are not handling types, variables, arrays and such optimally, and the garbage collector has a lot of work, which it then does when you experience the hitching. Not really sure. Have you searched on the officual forums? Perhaps asked about it there?

[Jim]

I use Blitz Basic still for rapid prototyping.  I often work on an fx in blitz and then move it to C for the real demo - for instance lomedux's water fx was done first in blitz.  But the demo couldn't have been totally written in blitz because of too much 3d.  I haven't seen that much of blitz max so don't know anything about lumpy performance.

Jim

[valis]

My suspicion is that it is indeed garbage collection that's going on.  That's the only thing that would explain periodic hitching.  But on the other hand things like "stars in a box" from here, and the bmax plasma demo, also offer hitchy performance on my linux box here.  This machine I'm talking about has some cruft in it and it could be that there are background processes that are kicking off or something, but even with high priority it still happens.

Since I'm mainly interested in doing 2D and simple software 3D games at this time it seems like Blitzmax is great. [for that purpose.  Obv. for x-ray crystallography apps or real time photon casting or whatever I would use c and assembly].

BTW also: many more polished products like Corruption: Invaders written in bmax are totally smooth.

Jim: what framework, if any, do you use in C?  Stupid question but what compiler do you use?  One reason I like BlitzMax so much is the extreme minimalism of the IDE.  I suppose I could code in Notepad++ and compile from the commandline with Mingw or whatever.   This is of course under Windows-- in linux minimal editors aren't really a problem.

No noob here, btw-- I wrote a 6502 assembler in Applesoft Basic in 1982 though I would be pretty hard pressed to do any assembly coding at this point.

You have to leave a little bit of time for the system to let it do its thing.

Understood.  How do you recommend that I do this?

[valis]

Just for reference, here is some code that exhibits the problem I'm talking about.  It happens about every 10-15 seconds, lasts about 1 second, and is barely perceptible.  Other things I've seen that are not written in Blitz do not seem to exhibit the problem.

This contains no framerate limiter or time delta and that might be the issue?

If nothing else, have a cheesy effect.

Code: [Select]

Global ob_list:TList = New TList

Type spacerect
Field x:Float, y:Float
Field vx:Float, vy:Float
Field sizex, sizey
Field colorr, colorg, colorb
Field transparency:Float

Function construct()
    Local s:spacerect = New spacerect
    s.x=Rand(640)
    s.y =Rand(480)
s.sizex=Rand(40)+5
s.sizey=Rand(40)+5
s.colorr=50
s.colorb=100
s.colorg=0
s.transparency=Rnd()+.5
s.vx = 0
s.vy = RndDouble()*5
    ListAddLast(ob_list,s)
EndFunction

Method draw()
SetBlend alphablend
SetColor(colorr, colorg, colorb)
SetAlpha transparency - .25
DrawRect x, y, sizex, sizey
SetAlpha transparency
DrawRect x+1, y+1, sizex-2, sizey-2
End Method

Method update()
y=y+vy
If y>700
y=Rand(480)
transparency = Rnd()+.5

EndIf
transparency=transparency -.01
End Method

End Type


Graphics 640,480

For Local i = 1 To 200
spacerect.construct()
Next


While MouseDown(1)=0

Cls


For foo:spacerect = EachIn ob_list
foo.update()
foo.draw()
Next
Flip

Wend



[zawran]

Understood.  How do you recommend that I do this?

There is a command called "Delay", which allows your program to wait a set number of milliseconds, which provides the system with time that it can use on background running tasks. Another perhaps better way would be to use an event driven main loop, where you setup a timer that determines how often you call logic and drawing functions, and for the remainder of the time it will just wait, and this allows the system to have the most time to perform background tasks. Most if not all commercial games produced with BlitzMax, and there are many, use a combination of event driven main loop and a delta/framelimiter timing system. There are a couple of examples of these setups in the code archieve section on the blitzmax.com website.

In your code example it should not be the garbage collector which is the cause, since you do not actually create and destroy any additional types, but just create a list of 200 types before the main loop, which never actually gets removed. The local S type that is generated in the contruct function is fairly quickly removed and so after being done with calling the function and the main loop starts, it should not really activate the garbage collection again, since there are no unused variables/types to deal with. Had you instead been removing the 200 types each frame and creating new ones, it might eventually cause some delay on the cleanup, but it would probably have to be in the thousands and not in the hundreds.

I am thinking that the issue with the hitching is down to having no delta/framelimiter, and that your system every now and then has some kind of background task, which delays your program just slightly, and when it catches up, you experience that hitching effect. The reason you have not noticed this on some non-blitzmax productions might be due to the fact that they use timing systems to prevent this effect.

[valis]

The reason you have not noticed this on some non-blitzmax productions might be due to the fact that they use timing systems to prevent this effect.

I meant that I have not noticed them on some blitzmax code.

Quite right regarding the delay and framerate limiter.  I would very likely not notice the chop if it was always running at that speed.  We are truly spoiled these days.

What delay time do you recommend?

[Jim]

what framework, if any, do you use in C?  Stupid question but what compiler do you use?

I don't use any frameworks, usually just OpenGL or DirectX libraries.  I use Visual Studio 2010.

In my delta timing I do two things - one, have a non-event driven loop that runs as fast as possible, but, if I see that my render time was much less than 1/60th of a second (16ms) then I will do something like
Sleep(16-(render_time+1));
in my main loop, which hands all the time I did not use back to the OS.

Jim
 

[zawran]

What delay time do you recommend?

I would probably suggest that you try out timers first, and using WaitTimer in the main loop.

Code: [Select]

SuperStrict

Graphics 640,480

Local time:TTimer = CreateTimer(30)

While Not KeyHit(KEY_ESCAPE)

WaitTimer(time)

maindrawing(MouseX(),MouseY())

Wend
End

Function maindrawing(x:Int,y:Int)
Cls
SetColor(255,0,0)
DrawRect(x,y,64,64)
Flip
End Function

In the code above, I create a timer which will tick 30 times per second. In the main loop I use WaitTimer to have the program wait on the timer tick. While it waits it allows the system to perform background tasks without the program interrupting. Once it ticks it continues the program and the drawing function is called. This works well as long at all the code running in the drawing function is able to get done before the next tick. If it is not, then it will jump a tick, and it might get jumpy again. To get around that you would have to use some kind of delta timing or tweening, where you allow the logic to compensate for the code not being able to get done before the tick was fired.

There are a lot of threads about this on the blitzmax.com forums, but I do not have something on hand that I can link to or post. It has been a while since I have done any code which needs timing because I have mostly been working on various tools, which does not require it.

[valis]

This fixed the problem somewhat.  My guess is that by adding movement based on delta time the problem will go away completely.  My Windows system doesn't experience it as badly as my linux box and I think there merely the addition of this delay will fix the problem.

Yup, did fix it.

[zawran]

Great that you were able to fix the issue.