Worklog update!

Hi,

I just posted a largely BlitzMax related worklog update:

http://www.blitzbasic.com/logs/userlog.php?user=1&log=507

oh
Threading ... It's great !

I agree, don't work yourself into an early grave or release buggy crap. Just keep on the good work, Mark!

Very interessting. What i didnt understand fully though is that do we need to call Flushmem any more or is it fully automatic, or did flushmeme become a wiser function that we still should call in the same situations as we do now?

And good news about the threads. Keep it up!

So, building a real GC finally?. Great.
Weird, reminds me something, *sigh*...

Anyway, you obviously worked pretty hard, and these are all definitely good news.

Very interesting stuff.

I just hope that the important concepts like FlushMem will be enough documented with a couple of examples.

Go on Mark ! Take your time, and keep us informed.

:-)

Sergio.

Always nice to see what's happening - thanks for the info.

Thanks for the update Mark!

Thanks, that was a great read.
It looks like there's alot of interresting times to come!! :D

ohh cool an update, thanks mark:)

Good read.

More frequent worklogs please! However big or small, they're nice to read and would keep the 'UGs' (update grumblers :P ) happy I'm sure.

Thanks
Tom

Great news to hear, I can't wait to try it out. Thanks for the info!

Good to hear that threading is being looked into as well.

Thanks for the update

Yay excellent read, it sounds like your doing wonders with BlitzMax! Nifty work, your doing an awesome job.

thank you!!!

I like this AutoFlushMems... I think i posted atter first release of blitzmax, that we need something like this.

Currently i add FlushMem at each Function + inside some "object-creating"-loops + Mainloop...

i can't wait for new update...

good job

err. sorry but what exactly is a GC?

Garbage Collector

Garbage Collector. It frees all allocated memory that isn't used any more.

This sounds very promising, lack of threading has had me looking in other directions.

Question for Mark if he reads: Is the GC implementation implemented as a thread? Your comments that the GC may be invoked while object state is questionable in case of CStrings seems to me that you implmented a Threaded GC, similar to .net?

If thats the case then at least I can do some native threaded code. If you can expose the basics cross platform capability without worrying about the entire runtime that would be huge!

Thanks
Doug Stastny

Wow, great news!

Thanks, Mark! Glad you're taking the time to do it right without killing yourself!

Thanks for the information and good luck for the further work!

Question which came up my mind was how realistic it is to hope for the 3d-engine beeing released this year...beside of a maybe preview christmas present.


Greetings,

taumel

Damn!!! No mention of imagebuffers.

I thread it all and all and I thread you're correcting in adding threading. it's about threading time.

Always enjoy reading updates :) thanks!

doh! ah thanks guys!

I would welcome this - regular small updates to the main core - rather than dabling with the GUI and the 3d engine and the compiler and bug fixes over several months.

Good to hear some official news though - rather than Mark's busy working on stuff - yes we know that! ;-)

Mark,

Speaking for myself only, the update is appreciated. While I don't think that anyone expects new versions weekly when there's so much to do as far as major systems (ui, 3d, etc.), I think that a lot of us would appreciate semi-regular updates on status, especially as there's so much to do as far as major systems ;)

I can understand not releasing buggy crap on Mac and Linux, but on Windows? Sheesh!

Thanks for the update Mark.

Great to hear this news. I think i am also one of the UGs who can't wait to get the gui modul onto the hd. btw: BlitzBasic was amazing, but BlitzMax makes coding like speaking whole stories to the computer and this one makes the app :p.
I am also one of the flsuhmem() haters, as i never explored a flushmem-like function in c# or other oop languages. Am i right, that with threading you can for example post the highscores to the webserver and continue playing your guesmaster2005-ish game while uploading the scores?

Great Job Mark!

Will there be GUI limitations or missing features if for example, one platform does not support feature X even though the other 2 do?

To help clarify that, lets say Windows and Linux GUI can get a system colour (Desktop background) but the MAC has no such function, would that mean both Windows and Linux have the feature disabled or stripped out?

probably

That was the most interesting Worklog entry I think I've ever read :)

Keep up the good work!

Nice update, very interesting. Always good to hear what's going on, even if we can't actually play with it. :)

Hi,

Thanks for the supportive comments everyone!



It will be fully automatic by default, but you'll be able to 'tune' it, turn it off and perform manual flushmems etc.

I still feel that manual flushmem is a good thing in your main game loop, as it keeps memory management nice and deterministic, and if you're 'pushing the 60hz' barrier or whatever this is important.

However, auto flushmem is really useful for non-realtime stuff, such as setup/initialization and apps like BMK.



Unfortunately, it's not gonna happen. I will however do a worklog on 3D progress very soon - I had some cool occlusion stuff happening when I last played with it that people may want to plan for. I also plan to release many 'beta demo' releases of the 3D engine as I go.



The CString issue is really to do with the fact that cstrings are not 'objects' as such, so really lie outside of the control of the garbage collector, eg stuff like:

wndClass.lpszClassName="Hello world".ToCString()

After this executes, who 'owns' the cstring? Not the Max app, as it doesn't have a handle on it. The WNDCLASS struct can't because it's just a plain c struct. etc...

To date, FlushMem would clean up these temporary cstrings. However, with auto flushmem there is the danger that a flushmem can kick in and destroy your cstrings without your knowledge. In fact, that possiblity really exists today - if you create a cstring then call a function that flushmem's you're stuffed if you still need the cstring 'alive'.

I'm currently leaning towards a 'mempool stack' system for dealing with problematic, non-Max mem allocations like this, but fortunately ToCString is pretty rarely used.



Not initially but I think it's inevitable this will have to happen sooner or later.

Wowzers, thanks for all the info, Mark. Definitely some good stuff to look forward to :c)

Any chance proper windowed mode support is coming in the future? I miss the ability to create various styles of windows like we can in Blitz Plus.

Bad news and it was kind of obvious but on the other side good news how you're going to deal with it! I'm looking forward to infos and beta demo releases then. :O)


Greetings,

taumel

Hi,I just wondered if the original blitz3d commands are created yet,
and if there are going to be several releases of the engine to allow people to create simple games or if you are just going to release the fininshed product at the end of development
thanks

No imagebuffers :( maybe squeeze it in? a possiblity? ;)

Paradox: i second that, i realy need imagebuffers! :D

Yup. Imagebuffers are dead useful.

Maybe I should be annoying about Imagebuffers, instead of Max3D... because I need them more!