BlitzMax 136 Now Up!

BlitzMax Forums/BlitzMax Programming/BlitzMax 136 Now Up!

marksibly(Posted 2009) [#1]
Hi,

Please visit product updates page of the account section for the latest BlitzMax update!


* Added an 'exception handler' to win32 appstub to aid with debugging. It doesn't throw a BlitzMax style exception, just displays a message box and does a DebugStop/exit (just exit in release mode).

* Changed min linewidth in d3d7max2d to 1 to match gl/d3d9.

* Added linewidth support to d3d9max2d.

* Added support for object resurrection to threaded GC.

* Modified compiler to prevent generation of default dtors in threaded mode.

* Removed hacks from dsound and openal audio drivers to deal with resurrected objects.

* New Max2d command: DrawSubImageRect image:TImage,x#,y#,w#,h#,sx#,sy#,sw#,sh#,hx#=0,hy#=0,frame=0

* Changed GCC optimization level in release mode from -Os (smallest) to -O2 (fastest)

* Fixed crash when changing from d3d9->gl drivers using 'raw' graphics commands, ie: without using Graphics/EndGraphics.



***** Boring tech stuff follows *****

This includes some semi-major tweaking to deal with a nasty issue involving GC and 'finalizers'.

In Blitz talk, finalizers are the Delete method in objects.

Finalizers are called when the GC determines an object to be garbage.

However, it turns out it's entirely possible for an object's finalizer to effectively cause another object (or indeed itself) to be 'resurrected'.

Here's an example:

This'll probably crash pre-136, as the final line is calling a method on a deleted object!

However, I've modified the GC system so this is now legal, or in other words:

Garbage collection may cause an object to be 'resurrected' after its delete method is called. This means that its methods may continue to be be called and its fields accessed etc. However, an object's delete method will only ever be called once.

This is all only important in a very few mind-bendingly rare situations (it was causing crashes in directsound/openal audio drivers) but you should probably be aware of it.

There are other ways to deal with this issue - the Hans Boehm collector does it a different way (which now explains a few 'not a bug' bugs) - but this seems like the most flexible for now. This is actually the approach .NET takes...

I've also made some general optimizations/cleanups to finalizers/destructors that may make it worth recompiling any 3rd party modules you have.

In particular, it used to be that a default destructor was created for every type (this was useful in refcounting GC for 'releasing' objects) - now, a destructor is only created if the user explicitly defines one (in threaded mode).


_Skully(Posted 2009) [#2]
Working great Mark!


degac(Posted 2009) [#3]
Oh, new DrawSubImage commands! Great! Thank you!


theHand(Posted 2009) [#4]
This'll probably crash pre-136, as the final line is calling a method on a deleted object!

However, I've modified the GC system so this is now legal, or in other words:

Garbage collection may cause an object to be 'resurrected' after its delete method is called. This means that its methods may continue to be be called and its fields accessed etc. However, an object's delete method will only ever be called once.

This sounds like being able to leave "Strict" out of code or something. It seems that this is either a bad way of doing it, or a really advanced topic? I've re-read it several times, I still don't really understand what this "resurrection" entails.
Has it been fixed so that objects don't "resurrect" themselves then, and if not (or if that's not what it is) the GC completely ignores them after they've been "resurrected", right?
Sorry for any trouble!


Tommo(Posted 2009) [#5]
Weird rebuilding behaviour...
After installed v136, my bmk keeps trying to rebuild whole module tree every time I build some module...

After minutes of scratching my head, I find that the new files installed is dated "12-04 16:41", but it's still 14:30 in my timezone, so the generated files can't get "newer" until 16:40 ...


therevills(Posted 2009) [#6]
Seems good, apart from GAF (Grey Alien Framework) needs tweaking in a few places due to it uses:

?Win32
  If TD3D7ImageFrame(image.frame(theframe))
    Local frame:TD3D7ImageFrame = TD3D7ImageFrame(image.frame(theframe))
    
    frame.setUV(rx / tw, ry / th, rw1 / tw, rh1 / th)
	frame.Draw x0, y0, x1, y1, x + origin_x, y + origin_y
    frame.setUV(0, 0, image.width / Float(tw), image.height / Float(th))
  Else
?


The frame.Draw now needs to use the new DrawSubImageRect parameters...


Brucey(Posted 2009) [#7]
Weird rebuilding behaviour...

Ah, the infamous New Zealand factor :-)


plash(Posted 2009) [#8]
* Changed GCC optimization level in release mode from -Os (smallest) to -O2 (fastest)
Yay!


QuickSilva(Posted 2009) [#9]
Thanks for the update.

"Changed GCC optimization level in release mode from -Os (smallest) to -O2 (fastest)"

Sorry if I have misunderstood but wouldn`t it make more sense to generate smallest for release mode and have fastest when in debug mode, for example when still in development?

Also is the new DrawSubImageRect a single surface way of drawing images?

Thanks,
Jason.


Czar Flavius(Posted 2009) [#10]
What does it even mean about GCC optimization?

And what is object resurrection? Is it a valid mechanism for code? Or a bad thing to be avoided? Why can't a resurrected object call its delete again?

Sorry I am just completely ignorant of these topics, but would like to learn more.


Muttley(Posted 2009) [#11]
@QuickSilva: What's the point in a Debug release being optimised for speed? It's only used during development so your end-product would see no benefit whatsoever!


xlsior(Posted 2009) [#12]
What does it even mean about GCC optimization?


GCC is the back-end C compiler used by Blitzmax. It's used to compile any of the C source code used by the modules.
Prior this was told to optimize these for size - now it's optimized for speed instead. The end result op changing the optimization setting is that any of the number crunching / logic type things in the background can run up to ~15% faster now, in exchange for a very slightly larger binary.

If you're just using the standard BRL modules, then you probably won't see any difference.


QuickSilva(Posted 2009) [#13]
Sorry, I obviously misunderstood.

For some reason I thought Mark meant the option changed compile time so that your code would compile faster at the expense of a slightly larger file size. I see that we are actually talking about program execution speed.

Jason.


xlsior(Posted 2009) [#14]
Yup, execution speed is better. It won't make a big difference for a graphical game perhaps since the actual video rendering speed doesn't change... But i can make a big difference in other areas: I'm working on a text parser utility, and it takes 15% less time to run from start to finish with the GCC speed optimization.


slenkar(Posted 2009) [#15]
nice update Mark!


JoshK(Posted 2009) [#16]
Cool.


theHand(Posted 2009) [#17]
Interesting stuff.
From JavaWorld:
Avoid finalizer abuse

The existence of finalization produces some interesting complications for JVMs and some interesting possibilities for Java programmers. What finalization grants to programmers is power over the life and death of objects. In short, it is possible and completely legal in Java to resurrect objects in finalizers -- to bring them back to life by making them referenced again. (One way a finalizer could accomplish this is by adding a reference to the object being finalized to a static linked list that is still "live.") Although such power may be tempting to exercise because it makes you feel important, the rule of thumb is to resist the temptation to use this power. In general, resurrecting objects in finalizers constitutes finalizer abuse.

The main justification for this rule is that any program that uses resurrection can be redesigned into an easier-to-understand program that doesn't use resurrection. A formal proof of this theorem is left as an exercise to the reader (I've always wanted to say that), but in an informal spirit, consider that object resurrection will be as random and unpredictable as object finalization. As such, a design that uses resurrection will be difficult to figure out by the next maintenance programmer who happens along -- who may not fully understand the idiosyncrasies of garbage collection in Java.

If you feel you simply must bring an object back to life, consider cloning a new copy of the object instead of resurrecting the same old object. The reasoning behind this piece of advice is that garbage collectors in the JVM invoke the finalize() method of an object only once. If that object is resurrected and becomes available for garbage collection a second time, the object's finalize() method will not be invoked again.

Destructor
Finalizer




In particular, it used to be that a default destructor was created for every type (this was useful in refcounting GC for 'releasing' objects) - now, a destructor is only created if the user explicitly defines one (in threaded mode).

Is this a workaround for sound issues like the ones zambini was having?


JoshK(Posted 2009) [#18]
The object resurrection sounds extremely dangerous. If you have things like a OpenAL sources or other third-party allocated items that get deleted in the Delete method, how should crashes be avoided, other than a lot of If statements in each method? Is there a good solution to this?


Dreamora(Posted 2009) [#19]
nice work on 1.3.6 :)

Though a question on the GCC flags: why not -O3 -ffast-math or at least offer an option for the later, as the majority of the games don't require scientific precision but would benefit significantly from the higher performance (this is basically my standard bmk modification on each new version, replacing the compiler flag to be more game oriented than simulation oriented)


degac(Posted 2009) [#20]

Though a question on the GCC flags: why not -O3 -ffast-math or...


Why dont' put an option in the IDE menu to choose the flag?
I think it's easy to implement and grant everyone the result needed.
It's like 'Threaded build' - it's present, but only who is interested in it use it (or ask about it!)

So we can have 'smaller', or 'faster' or 'faster-without scentific precision' or 'whatelse exist'


Grey Alien(Posted 2009) [#21]
Seems good, apart from GAF (Grey Alien Framework) needs tweaking in a few places due to it uses:
This is being dealt with by fantastic supportive customers (as you well know ;-)).

Thanks for another great release Mark. BMax is so good. Been using AS3 recently and BMax is lots better.


Armitage 1982(Posted 2009) [#22]
Been using AS3 recently and BMax is lots better.


OhOh... Don't know if I will ever return to flash now (again).

I probably miss some updates since 1.36
Is there anything new with projection matrix ?

I'm still with 1.34 and I don't use thread. Should I consider an upgrade ?
I already use a function for DrawSubImageRect but it's the only interesting thing I see out of the box.


MGE(Posted 2009) [#23]
"Been using AS3 recently and BMax is lots better."

To each their own. ;)


_Skully(Posted 2009) [#24]
I already use a function for DrawSubImageRect but it's the only interesting thing I see out of the box.


That will break with 1.36 because the frame draw now has 4 extra parameters. But the new command works perfectly.


Corum(Posted 2009) [#25]
I'm still with 1.34 and I don't use thread.

Same here. It seems (since 1.35), except for the virtual resolution thing, it's mainly a dx9 migration process.


Armitage 1982(Posted 2009) [#26]
Same here. It seems (since 1.35), except for the virtual resolution thing, it's mainly a dx9 migration process.

There appears to be numerous problems since 1.35 mainly with thirds party modules.
As I'm concerned since I don't need direct X for the moment I think it is wise to stay on 1.34.
But I do not want to miss nice new features too...


TaskMaster(Posted 2009) [#27]
Yes, there are changes in 1.36 that can break 3rd party modules. Mark definitely could have gone about the changes he made a little differently without breaking everything.

But the changes are not that much and as long as you have the source, fixing anything it broke is not that difficult. Without the source, you are screwed.


Chroma(Posted 2010) [#28]
Made new post...disregard this.