First contact

[Poshu]

Hi guys! Since it's my first post, I'll start with an apology: my english suck and I might ask dumb questions... =_=;;

So, I bought GLBasic a few weeks ago but I couldn't toy with it till yesterday; I'm an experienced code monkey but it's my first contact with game development; I choose GLBasic as a fast prototyping tool, yet I'm a bit disappointed (you could argue I should have tried the free version... And you could be right):
_This IDE is like... prehistoric! Is there any alternative?  If no, would anyone be interested in a more modern piece of software?
_Isn't GLbasic slow? 250~ small sprites and it's slowing down (maybe drawsprite isn't really the best solution? My CPU is the limit factor with one core running 100% capacity. I do not wish to multi-thread by the way)
_The help file is kinda plain, neither accurate nor complete, and quite frankly not easy to browse, any update on this side?
_The EULA isn't really clear about what I can and cannot do. I would like to add a precompiler (cause the language lack of some important features for me... Either that or I couldn't find those in the help file) is it ok for me to release that?
_I would like to blend a file manually, and couldn't find any function (something like transparentsprite ID,x,y,alpha ?). Any special knowledge to share?
_I can't find any function to release used memory (freesprite? anything?)

On the bright side, GLbasic is damn easy, I've been able to clone pacman in about 2 hours °_° I would have loved this when I was a teen!

[Ian Price]

Firstly, Hi Poshu.

Secondly, you ask some very good questions. However GLB is far more usable/powerful than your initial tests may seem - however, you like all good things, you have to put time and effort in to get the best things out.

Now for some answers to your questions -

The IDE, is tbh not the greatest in the world, but it's far from the worst. You also have to consider that for the most part GLBasic was developed (and continues to be developed) by one or two people and has evolved dramatically since the first version. If you don't like a feature of GLB, or can suggest an improvement then just say - Gernot (Kitty Hello) is always here and listens. He does what he can with the time he has, but still dedicates a massive amount of time to users, the product adn the forums - despite having a family and full time job.

250 small sprite limit (before slowdown) - well, I'm not sure of your processor speed, but that is very low. You don't say how you are displaying them, or if they are animated/alpha'd etc. There are various ways of increasing the number of sprites before slowdown occurs, uincluding the use of POLYVECTOR. These commands produce 3D objects that you can use for your sprites and they can be blitted en masse to provide an effective method of displaying multiple images (of ANY size and shape!) quickly. You can render many thousands without slowdown, even on handheld devices like iPhone, GP2X etc. Obviously these can't handle the same numbers as a regular pc, but they're better than displaying the same number as sprites.

Have you looked at other languages help files? Looking at recent ones, like PlayBASIC, BlitzMax, Monkey, Cobra (four recent ones that I've actually bought) you'll see that GLB's helpfile is fantastic. There are also online helpfiles which go above and beyond those with the product. There are also books available to buy (in .PDF form or printed) that cover far more than the language syntax and usage. Thank MrTAToad and others for those. If you are looking at more "Professional" languages, then they also generally have a higher cost to the user and many more people working on it than GLB. How many of those languages offer 3D, and multi-format support for pretty much every device available at a cost even similar to GLB, and don't require a licence fee to use?

With GLBasic you are free to create whatever you want, without restrictions, for commercial or free distribution. It's as plain and simple as that. How you use GLB is upto you.

If you set ALPHAMODE to a value other than 0.0 (something like 0.01) before displaying your alpha'd .PNGS you'll see them properly.

I'm not sure what you mean by "blend file" if you mean sprites, then look up the command above ALPHAMODE - you can have varying intesity of blend and fade etc. If you mean merge files, then I don't know, but you can create/import functions in different files and add them via the IDE into your current program.

Memory is automatically released (there are no garbage collection commands, as they are not needed), when re-using sprite and sound values, and when you exit GLB. Memory leaks do however come up from time to time as bugs, but these are usually plugged in the next update to GLB. You don't need to worry about memory, pretty much period. If you want to release memory from a sprite that you've loaded, just load another sprite at the same value, or use LOADSPRITE "",X - the original sprite will be released and removed.

Yep GLB is indeed "damn easy" and that's one of the many reasons that we all love it.

As for your PacMan game - care to share?

[bigsofty]

Welcome Poshu! 

Excellent reply there Ian BTW, maybe the makings of a "new-to-GLB" FAQ?

[Poshu]

Firstly, Hi Poshu.

Secondly, you ask some very good questions. However GLB is far more usable/powerful than your initial tests may seem - however, you like all good things, you have to put time and effort in to get the best things out.

Now for some answers to your questions -

The IDE, is tbh not the greatest in the world, but it's far from the worst. You also have to consider that for the most part GLBasic was developed (and continues to be developed) by one or two people and has evolved dramatically since the first version. If you don't like a feature of GLB, or can suggest an improvement then just say - Gernot (Kitty Hello) is always here and listens. He does what he can with the time he has, but still dedicates a massive amount of time to users, the product adn the forums - despite having a family and full time job.

250 small sprite limit (before slowdown) - well, I'm not sure of your processor speed, but that is very low. You don't say how you are displaying them, or if they are animated/alpha'd etc. There are various ways of increasing the number of sprites before slowdown occurs, uincluding the use of POLYVECTOR. These commands produce 3D objects that you can use for your sprites and they can be blitted en masse to provide an effective method of displaying multiple images (of ANY size and shape!) quickly. You can render many thousands without slowdown, even on handheld devices like iPhone, GP2X etc. Obviously these can't handle the same numbers as a regular pc, but they're better than displaying the same number as sprites.

Have you looked at other languages help files? Looking at recent ones, like PlayBASIC, BlitzMax, Monkey, Cobra (four recent ones that I've actually bought) you'll see that GLB's helpfile is fantastic. There are also online helpfiles which go above and beyond those with the product. There are also books available to buy (in .PDF form or printed) that cover far more than the language syntax and usage. Thank MrTAToad and others for those. If you are looking at more "Professional" languages, then they also generally have a higher cost to the user and many more people working on it than GLB. How many of those languages offer 3D, and multi-format support for pretty much every device available at a cost even similar to GLB, and don't require a licence fee to use?

With GLBasic you are free to create whatever you want, without restrictions, for commercial or free distribution. It's as plain and simple as that. How you use GLB is upto you.

If you set ALPHAMODE to a value other than 0.0 (something like 0.01) before displaying your alpha'd .PNGS you'll see them properly.

I'm not sure what you mean by "blend file" if you mean sprites, then look up the command above ALPHAMODE - you can have varying intesity of blend and fade etc. If you mean merge files, then I don't know, but you can create/import functions in different files and add them via the IDE into your current program.

Memory is automatically released (there are no garbage collection commands, as they are not needed), when re-using sprite and sound values, and when you exit GLB. Memory leaks do however come up from time to time as bugs, but these are usually plugged in the next update to GLB. You don't need to worry about memory, pretty much period. If you want to release memory from a sprite that you've loaded, just load another sprite at the same value, or use LOADSPRITE "",X - the original sprite will be released and removed.

Yep GLB is indeed "damn easy" and that's one of the many reasons that we all love it.

As for your PacMan game - care to share?

I could build my own IDE quickly enough to avoid putting some burden on Gernot shoulders; I was just wondering if there was anything better already :p

I've got a phenom II X6 3.6 ghz processor, not high end but not too shabby either; but I just discovered that the slow down came from using a few screens as back-buffer for some effect; but I'll have a look to 3D solutions (even though 3D scares the hell out of me)

Nop, I just know my lovely MSDN (I know it's unfair to compare glbasic with visual studio but, hey, that's all I've been working with for the last 5 years)

Cool! That's a nice approach there... I'm used to dev with Microsoft tools and I swear to god I hate those un-readable EULA.

Yeah, I finally got that, I just cannot get why the alphamode is switched back every time there is a showscreen (actually, it took me time to understand that showscreen was handling the window events too xD) just not my usual dev logic I guess.

Omgwtfbbq, you can do this?!

Code (glbasic) Select Expand


CREATESCREEN 0,0,32,32
USESCREEN 0
DRAWRECT 0,0,32,32,0
USESCREEN -1

WHILE TRUE
CLEARSCREEN 16777215
ALPHAMODE -0.45
DRAWSPRITE 0,0,0

ALPHAMODE -0.5
DRAWSPRITE 0,32,0
SHOWSCREEN
WEND

It was obviously too easy... Sorry >.<;

No memory management for the user? That's sweet! I can deal with that kind of feature

Thanks a lot for your help!
Yeah, I'm probably going to release my pacman as my first game evaaaaar, but I would like to pimp it up a little before that :p

[Ian Price]

Getting to know POLYVECTORs has nothing to do with using "real" 3D or the 3D command-set. Have no fear - I'm terrified of 3D too (strictly 2D, although I have dabbled), but use POLYVECTORs quite a lot. Once you learn how to harness their power, you really will be laughing.

No need to use backbuffers (unless you mean images as backgrounds, you could use POLYVECTORs for these too BTW).

Yes MSDN is indeed an unfair comparison - but then you could you recreate PacMan in two hours with tools from M$?

Pimp away, we all love to see/hear what others are working on.

[Leginus]

if it helps, here is my polyvector function which you can call very similar to drawsprite.

Code (glbasic) Select Expand



FUNCTION PolyDrawSprite : SprNum%,Xpos,Ypos,W,H,PolySprite
//**************************** ************************
//*  Draws polyvector sprite
//*
//*   Called By :  (GameFunctions) - DrawHero
//*
//*   Calls : None
//***************************************************

IF PolySprite = 1
STARTPOLY SprNum
POLYVECTOR Xpos, Ypos, 0, 0, RGB(255, 255, 255)
POLYVECTOR Xpos, Ypos+H, 0, H, RGB(255, 255, 255)
POLYVECTOR Xpos+W, Ypos+H, W, H, RGB(255, 255, 255)
POLYVECTOR Xpos+W, Ypos, W, 0, RGB(  255, 255,  255)
ENDPOLY
ELSEIF  PolySprite =0
DRAWSPRITE SprNum,Xpos,Ypos
ENDIF

ENDFUNCTION


You can call it like this :

Code (glbasic) Select Expand


PolyDrawSprite(54,100,200,50,60,1)

PolyDrawSprite(imgNo,Xpos,Ypos,Width,Height,1) 

The"1" on the end switches between normal drawsprite and polydrawsprite.
You only have to provide width and height for a polydraw sprite, otherwise it is ignored.

This doesnt use all the polyvector functions such as colour tinting and stretching etc. but as a simple sprite to polyvector conversion its easy if you don't know how and saves typing it all in every time

[MrTAToad]

Must see if using POLYVECTOR is faster than sprites...

[Poshu]

No need to use backbuffers (unless you mean images as backgrounds, you could use POLYVECTORs for these too BTW).

Yes MSDN is indeed an unfair comparison - but then you could you recreate PacMan in two hours with tools from M$?

I'm using backbuffer to create a few background image that change slightly at every frame... I'll still have a look to polyvectors then.

I could easily clone PacMan with GDI+; but it's unfair too, I'm working with it everyday :p

if it helps, here is my polyvector function which you can call very similar to drawsprite.

Code (glbasic) Select Expand



FUNCTION PolyDrawSprite : SprNum%,Xpos,Ypos,W,H,PolySprite
//**************************** ************************
//*  Draws polyvector sprite
//*
//*   Called By :  (GameFunctions) - DrawHero
//*
//*   Calls : None
//***************************************************

IF PolySprite = 1
STARTPOLY SprNum
POLYVECTOR Xpos, Ypos, 0, 0, RGB(255, 255, 255)
POLYVECTOR Xpos, Ypos+H, 0, H, RGB(255, 255, 255)
POLYVECTOR Xpos+W, Ypos+H, W, H, RGB(255, 255, 255)
POLYVECTOR Xpos+W, Ypos, W, 0, RGB(  255, 255,  255)
ENDPOLY
ELSEIF  PolySprite =0
DRAWSPRITE SprNum,Xpos,Ypos
ENDIF

ENDFUNCTION


You can call it like this :

Code (glbasic) Select Expand


PolyDrawSprite(54,100,200,50,60,1)

PolyDrawSprite(imgNo,Xpos,Ypos,Width,Height,1) 

The"1" on the end switches between normal drawsprite and polydrawsprite.
You only have to provide width and height for a polydraw sprite, otherwise it is ignored.

This doesnt use all the polyvector functions such as colour tinting and stretching etc. but as a simple sprite to polyvector conversion its easy if you don't know how and saves typing it all in every time

Thanks, I'll toy with that (and look for further exemples with polyvectors.)

[MrTAToad]

You might be interested in this Sprite Speed Tester Program.  It moves, rotates ans scales 1000 128 x 128 sprites, and which should all be done at proximately 59 FPS

[attachment deleted by admin]

[Leginus]

yep that runs fine here.
Is that POLYVECTOR or normal sprites?

[Kitty Hello]

Move the clearscreen out of the loop. It will remember the colour and clear on showscreen automatically.

[Qedo]

SpriteSpeedTester

On my notebooK Centrino 1.8Ghz Nvidia 8400 13-20FPS

[MrTAToad]

Not surprising with the 8400 - scaling is graphically expensive.

It does try to be as smooth as possible though.

[Wampus]

if it helps, here is my polyvector function which you can call very similar to drawsprite.

I also wrote some code to do a similar thing - to replace all standard sprite functions (ROTOZOOMANIM, etc) with polyvectors. That way I could retrofit older apps for a polyvector speed boost. Made a good deal of difference

[Slydog]

A lot of good advice here.

If you want maximum speed, I would suggest a modified DrawPoly() function that doesn't use a new material every call.
(Unless GLBasic does this automatically, but I didn't see that mentioned anywhere)

Something like (sorry for using my TXyXy type, didn't want to redo this without it, but you get the idea):

Code (glbasic) Select Expand

TYPE TXyXy
    x1%
    y1%
    x2%
    y2%
ENDTYPE

// (uv1) 0___2
//       |  /|
//       | / |
//       |/__|
//       1   3 (uv2)

// xy_px :: Top-Left and Bottom-Right screen location
// xy_uv :: Top-Left and Bottom-Right texture location
FUNCTION DrawPoly: xy AS TXyXy, uv AS TXyXy, colour%, sprite_id%=-1, end_poly%=FALSE
    STATIC sprite_id_prev%=-1

    //[EDIT] Add this to make sure this isn't called out of order
    IF sprite_id_prev < 0 THEN RETURN

    // New Material?
    IF (sprite_id >= 0) AND (sprite_id <> sprite_id_prev)
        sprite_id_prev = sprite_id
        STARTPOLY sprite_id
    // Or else same material but different poly strip
    ELSE
POLYNEWSTRIP
    ENDIF

    // [EDIT] Add this to make it safer:
    IF end_poly=TRUE THEN sprite_id_prev=-1

    POLYVECTOR xy.x1, xy.y1, uv.x1, uv.y1, colour // TL
    POLYVECTOR xy.x1, xy.y2, uv.x1, uv.y2, colour // BL
    POLYVECTOR xy.x2, xy.y1, uv.x2, uv.y1, colour // TR
    POLYVECTOR xy.x2, xy.y2, uv.x2, uv.y2, colour // BR

    IF end_poly = TRUE
        ENDPOLY()
    ENDIF
ENDFUNCTION

// Usage:
LOCAL xy AS TXyXy
LOCAL uv AS TXyXy
... setup xy and uv ...

// Start a new polystrip with sprite id 'spr_tileset' and keep it open
DrawPoly(xy, uv, rgb(255,0,0), spr_tileset)

// Draw an additional polygon using the previous sprite id, and keep it open
DrawPoly(xy, uv, rgb(255,0,0))

// Draw a final polygon using the previous sprite id, and close it to further polygons
DrawPoly(xy, uv, rgb(255,0,0), -1, TRUE)

// Draw a new polygon series using sprite id 'spr_player' and close it to further polygons
DrawPoly(xy, uv, rgb(255,0,0), spr_player, TRUE)

[Edit] This may not work without bugs, I modified my own DrawPoly() to illustrate, but didn't test anything.