1.12 and Max GUI discussion

Hi all,

Whats your impressions so far? You've waited 5 months and it's finally here. Also post your impressions of 1.12...

edit: so far, I've found out flushmem is GONE! and also I cannot find memalloced() - any idea what the replacements are..?

First impressions good though... Well done Bmax team!

Have to leech it yet ... at least I'd hoped for a few more gadgets.. but alas.. they're not difficult to make yourself.

Is there anything like MDI possible?

Rob: MemAlloced is replaced with GCMemAlloced.

The IDE: still horrible despite hoping to see improvements. I think there's actually been degradation of the IDE, as I can no longer CTRL+Tab to switch file tabs.

Source code to BMK: Happy that I got this, although it doesn't help me much now that I know the preprocessor is part of BCC itself.

Source to docmods: Useless as it sucked in the first place.

Documentation: The visual aspect has improved but otherwise it's the same crap. Still better to just browse the module source currently.

Runtime changes: Glad the FlushMem is gone, although would've liked it left in place for the sake of backwards compatibility. Oh well, all it takes is Find/Replace of "FlushMem" to "'FlushMem". The lack of GCMalloc bugs me as now I can't rely on using it at all, so that's an extra line for every call to that I've made.

Would've liked GetGraphics to remain as it was very convenient for getting all the info required with a single call.

Going to have to inspect the GC modifications a little more thoroughly before I can comment on that.

At a first glance, for some reason my IFFILBMloader module no longer seems to be working. A quick fiddle shows that it's loader routines aren't being called. I can't imagine why - it uses exactly the same plugin method as the bmploader module.

At first glance, it appears that any module outside the usual brl.* or pub.* directory structure isn't being used. At all. Testing another module results in command not found errors. This is after recompiling the modules... Which appears to work fine.

Troubling. All I wanted to do was see if TileImage finally took Scale into account ;]

This makes me want to buy BlitzMax even more...

Kudos to Blitz Research on MaxGUI, really impressed, actually expected something kinda half assed..

but question... you all expected someone to ask it... When I Max 3D out? :P ROFL... sorry just had to ask

I like the simplification - vwait is back and flushmem is gone... thats cool. I use SuperStrict... nice.

Any clues on what speedups have occured if any?

Toby, you now need to explicity import modules outside of brl and pub.

I noticed. Thanks for officialising that. I'm off to read Releasenotes.doc - it's probably in there anyway ;] (EDIT : nup:)

---

My favourite quote from versions.doc :

I think the EventHook mechanism is overly complex, but otherwise I think it's a definate overall improvement. The GUI probably does everything I'll ever need it to.

You can make a pre-preprocessor for it tho'. :o>

How cool is it to be able to modify the IDE you're modifying the IDE in.

Proportionately cool to compiling a language compiler in the language the compiler compiles for. =]

Hi FlameDuck, what do you mean by that? Which aspects do you find overly complex?

My current impression is that my game lost about 500 FPS in OpenGL, so I went back to 1.10. Has anyone else done any speed tests?

* edit *
I did more testing, here are some real figures

1.10
OpenGL - 4,900 FPS
DirectX TnL - 2,800 FPS
DirectX HAL - 2,300 FPS

1.12
OpenGL - 4,500 FPS
DirectX HAL - 2,100 FPS

Why wasn't TnL HAL added as an option?

what gives?

DisableGadget(Desktop())

Nothing is happening!

They hijacked the CTR-Left and CTR-Right shortcuts to do that instead, so text navigation is now crippled.

Please switch these two items back to what they were and restore the windows default behaviour. :-?

(I'm surprised exactly how crippling this is to my editing abilities... You don't really realize how much you depend on something as simple as that until it gets taken away)

Great..

I never would have thought it possible to make the BMax IDE worse, but I hath been proven wrong.

That aside, I'm happy with the update so far, despite the lack of anything that really compels me to use it.

Thoughts on the presentation end:
The GUI product page should have an image with the same GUI program, compiled for 3 seperate operating systems, all side by side. At the moment, it is not a very good demonstration of its cross-platformness. Also, there should be a particular BlitzMax official modules products section, because having them just listed under BlitzMax in the main products page may get a bit overwhelming... and confusing for people who don't own BlitzMax and come up with some silly idea that they can buy a module and instantly be able to program stuff for it without the full purchase of BlitzMax.


Regarding IDE... I'm actually glad that BlitzMax's IDE caused people such irritation. It is probably a reason why BLiDe came into existence, which is a surprisingly featureful IDE (and was quite good... last time I used it) :)
Also, it has to be fast, because the language runs on some pretty old computers -- so it should be able to operate on them, too.



Shouldn't you be able to turn off the memory management and do it manually?

You can--see release notes.

I have played around with BMax since I got it and have been impressed, but did not use it because of the sound issues and the lack of a GUI. I have been sticking with B+ in the meantime.

My sound issues appear to be fixed (still waiting to hear from two beta testers). I love the GUI and it does everything I need. Now it is time to start porting WIP projects from B+ to Bmax.

What does SuperStrict do? I couldn't find anything in the docs about it.

Superstrict forces you to specify a type for a variable.

eg. MyInt = 0 will throw an error. MyInt:int will not because you have specified what type the variable is ie int, String, Float.

No, that's Strict. What does the Super part do? I heard talk about variable name case sensitivity, but that was as a request.

Well, if I use Strict only I don't have to specify a type and the compiler doesn't complain. If I use SuperStrict the compiler complains because I've not specified a type for a variable.

BlitzMax isn't a case sensetive Language, might be in the future. A quick test using SuperStrict shows that you can have myInt, MYint mYiNt and get a duplicate identifier error when you try to assign a value to it twice.

No, that's superstrict

Strict
Local a=1
Print a

SuperStrict
Local a=1
Print a

No strict just wants you to declare variables, superstrict is rob's cup of tea. Does what amon says. It's all Rob wanted for christmas, poor sausage.

Strict forces you to declare variables before use either Global or local. SuperStrict forces you to declare what Type a variable is.

Unless I have a different version of BlitzMax than everyone else.

Oh all this time I had no idea. I've been using Strict as SuperStrict anyway...

I like hooters.

[edit] Why did i type that?

I'm contagious.

I noticed a drop in FPS in my games as well, and we're not the only ones...

The GUI is sweet. I had no idea it was this easy...

that's probably because BRL has been slaving away, doing the hard work for you!!! ;)

The complete and utter lack of abstraction. I would have prefered an Observer pattern style implementation, like Javas.

I'm sure I'm in a majority tho'. [Edit]Minority, obviously.

Eikon - a drop from 4900 frames per second to 4500 frames per second is a mere 0.018 milliseconds difference - I find it hard to believe you could notice such a difference.

(4900 frames per second = 0.204 milliseconds per frame, 4500 frames per second = 0.222 milliseconds per frame)

If your game runs at over 4000 frames per second what is it doing?

The IDE is a MaxGUI program so surely making improved IDE's should be very simple.

When you work on optimizing your code to get every bit of speed possible, a drop of 400 FPS is a big difference. I could render another tile layer for that cost in frames. Updates should speed things up, not slow them down.


It's a side scrolling game. I'm rendering a player, a double layer tile map @ 640 x 480 with collision, and a custom GUI. I'm not testing a blank screen or anything. 4,000 FPS is nothing if you've seen some of the machines people here have, I recall seeing over 7,000.

I'm wondering how you are measuring these frame rates?
You can't be using millisecs, 'cause it won't give you accuracy on anything lower than 1 millisec (ie. 1000 fps)

Global fpsCount = 0, fpsCurrent = 0, fpsTime = MilliSecs() + 1

Repeat
fpsCount:+1
If MilliSecs() >= fpsTime Then fpsCurrent = fpsCount; fpsCount = 0; fpsTime:+1000

DrawText fpsCurrent, 1, 1
Flip; Cls
Forever

and to circumvent the negative MilliSecs() integer rollover problem, I use a custom MilliSecs() function that starts counting at 0 each run and seed with GetTickCount()

Unless of course dodgy shortcuts were being used the first time around, or a code improvement has made certain aspects more complex.

Eikon: Have you tried disabling the auto garbage collection and doing it manually? Just wondering, but perhaps the garbage collector is being called at slightly less convenient times and taking a little longer.

Eikon;
DOH'! :p

Thanks for the code example..
I must admit, I never thought of doing and fps count that way.. I always kinda did it the other way around.. (using the amount of millisecs passed since last loop)

I don't see how Eikon is being honest. I have a faster pc thank Eikon's by far, with incredibly low latency ram, and a better graphics card... which runs Quake4 at high framerates.

And it does not hit 4000 even with a blank screen on Eikons test. Methinks Eikon is being dramatic and silly, possibly calling his FPS counter in the wrong places.

A demo I wrote using GL to display some skinned animated B3D files gave me 280 FPS in 1.10, and now it's 325 FPS in 1.12.

Nice!

you cant go much over 2500 fps and still be displaying and measuring properly. A more useful test is to pile on the meshes and stuff then measure.

That's less than a fraction of a millisecond. Are you actually caring about this?

Is more functionality going to be added to the GUI module, or is it considered finished?

I wish mark had taken a look at delphi before doing the gui.

What do I have to gain by posting a false FPS reading? Nothing.


Please don't insinuate that I'm a liar because you can't properly configure your PC, and I'm pretty sure I can locate my main loop.


We're talking about losing FPS, no matter how you wanna slice it. I'm trying to program for low spec PCs, not everyone has a machine like I do. Those extra frames will matter when the user has an integrated Intel GPU. I've already done testing and what runs at 4,000 for me, runs at less than 800 for someone on a PIII 733mhz and Geforce 3 32MB. My game is far from finished, it can only get slower from here. So yes, I am caring about this.

@Gabriel: Nope, I'll try that now. Thanks.

I am simply stating that the update generally made things slower, I don't see why people feel the need to defend against that.

Geez, only 800? How will you ever realize your artistic vision with that kind of frame rate? Clearly this is something that needs to be addressed immediately.

Mark!


The reason? Experience. The kind of numbers you're talking about are irrelevant.

And if he put more models in his game or what not it would reach a point where you would notice.

Do you think a P3 733 / Geforce 3 32MB is exactly low spec? I don't. From my testing I see a reason to be worried. I have many more things to add to the game, like FPS killers such as tiled backgrounds.


If a single customer dips under 60FPS because of the update, it will not have been irrelevant to me. It seems we have a difference of opinion.

Good luck!

With regards to speed issues ..

have you guys tried manual garbage collection?

GCSetMode 2 ' set to manual garbage collection

Repeat
  ' do stuff
  GCCollect ' perform the equivalent of a FlushMem
  Flip
Forever

It's also worth mentioning the fact that you can also put simple C/C++ in BlitzMax and compile/run.

Save this with a .c extension then F5 to go:

#include <stdio.h>

int main( int argc,char *argv[] ){
   printf( "Max made me\n" );
   return 0;
}

The sites taking a hammering at the moment. There are close to 100 users online as I type. News spreads fast hey!

Watch out, Eikon was monologuing.

har, har... get off my case

I tested that and it gave a small FPS boost, it's no where near 1.10 readings, though. In the update thread it looks like others are having problems too. It seems the speed issue can be fixed, but no one can nail down exactly what they changed to correct it yet.

Or you'll...?

there'll be no ultimatum, I think we're above this childish crap

Agreed?

if you don't reply, you'll ruin "One Eyed Jack's" only reason for being here.. (trolling)

Anyway, I like the new GUI stuff, although it lacks a bit compared to Visual Studio right now, so for applications there's an obvious choice.

However, for simple game settings menus or similar stuff, its just awesome to have in the BlitzMax package.

Welcome to the wonderful world of BlitzPlus, where so many people have been complaining... until now =] If ever there was a way to correct a 'wrong' (in some people's eyes, not mine necessarily) it's giving away a free superior product.

If you are making a game, most people playing a game will have already taken the splurge long ago and spent at least $20 on a real TNT budget graphics card.

Unless you are using GDI for your games, you will always have problems with the mobo chips like Trident, Intel, SiS, Savage. None of those "properly" support DX & OpenGL. There is a difference between compatibility and compliancy.

But since gamers will have real graphics cards, this shouldn't be an issue. I have tested BMax stuff on a $20 TNT, $40 GeForce and budget Radeons and not had any speed issues whatsoever.

I am also getting the same framerate in 1.12 that I did under 1.10 and these are "test programs" other Max users wrote, so my shoddy coding cannot be questioned.

Yup. Thats far more sensible Brice. In reality there's very little difference between the two :)

Eikon,

Those of us on laptops, with no 3D graphics card, appreciate your efforts. Don't pay attention to the naysayers... get every ounce of speed out of your game.


The most profitable game market is the "casual gamers" market... people who want to play a game during lunchtime on their office PC, or people who are on a laptop and want something fun to do on a plane, or things like that. There are real reasons for optimizing as much as possible.

The most profitable market is the shut-the-hell-up market, people who do whatever I happen to think is right at any given moment.

I'm all for squeezing extra FPS out of code but for the life of me I don't understand why people are reluctant to upgrade their hardware. In the UK(Take Dell for instance) you can buy a half decent PC for around £250 - £350.

It's almost as if coders are at the mercy of people who have archaic hardware. IMO if someone has a 10 year old pc and can't afford to upgrade it then the likelyhood of them buying you game is 0.

Not really, it can easily be the choice between buying a game *or* a new piece of hardware.

In which case the guy buying a new computer has the likelyhood of '0' to buy your game.

Anyway, when it comes to upgrading a computer, a lot of people are in the "if it ain't broken, don't fix it". category. Most people won't rush out and buy a new computer if one random game they try isn't smooth. A lot of people will wait until 'too many' games don't work right.

Since you *know* that there are a ton of people with mediocre system specs out there, you ought to at least take that into consideration when creating a game. sure, you can go overboard optimizing as well, but don't automatically assume that everyone should just buy a multi-gigahertz machine to play your pacman clone -- it simply isn't going to happen.

Nicely put.

Except if he's just bought a new computer, just to play your game, he's not going to not want to buy it next month. Win/Win situation if you ask me. He gets newer hardware, you get to write more games.

You have to look at this realisticly. What's more expensive, new(ish) hardware, or programer hours? If you can buy a Dell PC for arround £250, there's little reason to spend £5000 on programmers to optimize your code. It's just as cheap to buy those 20 customers with old computers a new one.

>Not really, it can easily be the choice between buying a
>game *or* a new piece of hardware.

Exactly!

>In which case the guy buying a new computer has the
>likelyhood of '0' to buy your game.

Actually he buys that game and next month he buys another game and so on, and pretty soon he's got lot's of games and a 10 year old PC which works well, but not well enough to play new games on.


Andy

If you're making casual or 2D games, the target pc isn't important so long as it can run reliably.

Far more important is finishing a game - something most people don't even manage.

I was going to make my usual comment here but then I thought "Hey, I got a business to run - I don't have time for this. I'm off to *finish* another bit of software"

I just optimised my game so that the min specs dropped from 2GHz to 300MHz and it plays and looks exactly the same, it was worth it, much bigger market.

And most of these "casual games" have required a DX compliant video card for the past seven years.

My minimum test machine is a P2 500MHz, 128MB RAM, Geforce 2 MX 400 ($20 card), running XP. BMax flies even on something as ancient as this. That is the minimum I shoot for and this is a VERY old system.

I allow people to adjust the refresh rate for the game, and for people with POS cards, they can enable delta timing that will make the game look good even on Trident & Savage mobo chips.

A 3D card that is DX or OpenGL compliant IS a minimum requirement for BMax.

Brice, that is the recommended specs for the casual market funnily enough. Popcap are shooting for a 500mhz P3 with a 2D or 3D card.

DX7 3D cards are more common than 2D only cards now. This is the reason I embraced blitzmax. It is clearly superior on every level for making 2D style 3D accelerated games.

Not even popcap + C++ is as good.

Of course making 3D games is something else entirely and we shall just have to see. Impressions are good though.

I saw a poll on a "casual gamers'" site the other week that asked what CPU speed peoples' PCs had. Can't remember what No1 in the poll was, but No2 was "I have no idea!". :/

That's certainly a valid point. Can you remember which site it was? I'd be interested in seeing the numbers...

big10p: I saw the same thing too!

Popcap doesn't need to target 3D cards, because the Popcap Framework supports software rendering, which works quite nice for the type of games they put out which are rarely bouncing a lot of sprites around.

If Mark would implement the "Software Driver" from B+ into BMax, that would solve this issue for BMax and it would work fine on ANY system.

I am not fond of the 2D in 3D, but there comes a time when you have to accept change, and I agree BMax is heads and tails above the competition.

FlameDuck: It's over at www.retro64.com - bottom-right of the main page.

remember with all polls, they are weighted by the type of people that answer them. Retro 64 may attract a market with higher spec PCs than say a puzzle games site. So only 1/3 of the votes have > 2000MHz, 20% don't know (they could be higher OR lower, who knows) 18% sitting in a confortable 1-2GHz band but LOOK ... 23% less than 1GHz, that's a big slice or market and profit. Shows that you are better off spending you time making it work on slower PCs than bothering with a Mac version, sorry but it's true.

Eikon -
Any progress in figuring out the source of the speed loss? There are quite a few people reporting similar issues and a near 10% decrease is significant IMO. If you have a small bit of code to show the difference, please post so I can try it.