GLBasic and a few OOP-like features:

Previous topic - Next topic

mahan

Let's build ourselves a basic OOP-like class like this (compiled as a console app):

(TPerson.gbas:)

Code (glbasic) Select


TYPE TPerson

_name$
_age%
onAgeChange[] AS TPerson_EventProto

ENDTYPE


PROTOTYPE TPerson_EventProto: person AS TPerson

FUNCTION TPerson_Create AS TPerson: name$, age%

LOCAL newPerson AS TPerson

newPerson._name$ = name$
newPerson._age = age

RETURN newPerson
ENDFUNCTION

FUNCTION TPerson_getAge%: person AS TPerson
RETURN person._age
ENDFUNCTION


FUNCTION TPerson_getName$: person AS TPerson
RETURN person._name$
ENDFUNCTION

FUNCTION TPerson_setAge%: person AS TPerson, newAge%
person._age = newAge%

FOR i = 0 TO LEN(person.onAgeChange[])-1
LOCAL currCallback AS TPerson_EventProto
currCallback = person.onAgeChange[i]
currCallback(person)
NEXT

ENDFUNCTION

FUNCTION TPerson_registerOnAgeChangeHandler: person AS TPerson, callbackFunc AS TPerson_EventProto
DIMPUSH person.onAgeChange[], callbackFunc
ENDFUNCTION



Now let's test out new "class" with this little test-app:

(OOPTest.gbas:)

Code (glbasic) Select
main()


FUNCTION printToStdOutOnAgeChange: person AS TPerson
STDOUT "EVENTHANDLER RESPONCE: Age was just changed to " + TPerson_getAge(person) + CHR$(10)
ENDFUNCTION

FUNCTION main:

LOCAL mahan AS TPerson

//Creating the Mahan instance
mahan = TPerson_Create("Mahan", 32)
// Registering eventhandler"
LOCAL tempFuncPtr AS TPerson_EventProto
tempFuncPtr = printToStdOutOnAgeChange
TPerson_registerOnAgeChangeHandler(mahan, tempFuncPtr)
//Uncomment line below to prove that several handlers will be called correctly
//TPerson_registerOnAgeChangeHandler(mahan, tempFuncPtr)


//testing "getters"
STDOUT "TPerson: name=" + TPerson_getName$(mahan) + ", age=" + TPerson_getAge(mahan) + CHR$(10)


STDOUT "Now changing age to see if callback fired: " + CHR$(10)

TPerson_setAge(mahan, 33)

KEYWAIT

ENDFUNCTION


This is of course not full OOP with polymorphism etc., but still a funny demo how functionality can be grouped together with a data-structure with event-handlers that can be stacked on single events :)

(note: Remember I'm a GLBasic newbie, so if I use something wrong or things can be written more nicely I'm eager to learn more)

Schranz0r

OOP in GLB ( Using INLINE and GLBasic-Inline-feature!) :

Code (glbasic) Select


OOP_Main()


FUNCTION CloseGLB_Namespace:
ENDFUNCTION

INLINE
class engine{
public:
void init(){};
int run(){return 1;}
void cls(){CLEARSCREEN(RGB(0xff, 0xff, 0xff));}
void cls(DGInt _rgb){CLEARSCREEN(_rgb);}
void drawall(){SHOWSCREEN();}
};

class cSprite{
public:
int id; // spriteID
DGStr name_Str; // name
int sx,sy; // SpriteSize
int x,y; // position

cSprite(DGStr name_Str){
id = GENSPRITE();
LOADSPRITE(name_Str,id);
}
~cSprite(){delete this;}

void DrawImage(int x, int y){
DRAWSPRITE(id,x,y);
}

void SetPosition(int x, int y){};
};

engine* game;

ENDINLINE


FUNCTION OOP_Main:
INLINE

game->init();

cSprite* sprite = new cSprite("icon.png");

FOR(;;){
game->cls(RGB(0xff, 0x00, 0x00));
sprite->DrawImage(10,20);

game->run();
game->drawall();
}
DELETE sprite;
END();

ENDINLINE
ENDFUNCTION


Sorry i`m not so good on OOP :D
I <3 DGArray's :D

PC:
AMD Ryzen 7 3800X 16@4.5GHz, 16GB Corsair Vengeance LPX DDR4-3200 RAM, ASUS Dual GeForce RTX™ 3060 OC Edition 12GB GDDR6, Windows 11 Pro 64Bit, MSi Tomahawk B350 Mainboard

mahan

Thanks for your reply. Good hints on getting to write c++ (which surely has it's uses). I'll do it your way the day GLBasic is to slow for my purposes but for now I'll continue to write in the "basic"-part of GLBasic :)

Kitty Hello

The C++ OOP way is *slower* than the C-Style BASIC way. Don't thing C++ is faster than C. Wrong. It's more overhead.
It's just easier and there is some nice things you can get if you manage the beast. But not for speed. Maybe with using templates for different constant template arguments where the compiler can optimize out "if" checks that are not used.

Really: I'm a professional C++ programmer in my full time job. I really know C++ and I'm fast with that. But when it comes to programming games, I stick to GLBasic because I'm much much quicker with that.. OOP starts to get interesting for large projects like Corel Draw.

com_1

>>  I'm a professional C++ programmer in my full time job.
>>  I really know C++ and I'm fast with that.

GLBasic - good language.
But why not remake GLBasic - a scripting language ?

Kitty Hello - du sprichst - C++.
Warum GLBasic lansammer als BlitzBasic ?
Kannst du aus - GLBasic script sprache tun ?

bigsofty

Scripting languages are not allowed on the iPhone.
Cheers,

Ian.

"It is practically impossible to teach good programming style to students that have had prior exposure to BASIC.  As potential programmers, they are mentally mutilated beyond hope of regeneration."
(E. W. Dijkstra)

gigios

Quote from: com_1 on 2010-Apr-29
GLBasic - good language.
But why not remake GLBasic - a scripting language ?

Why do you want make GLBasic a scripting language ?

I think that compile in native code is a benefit and not a disadvantage  :whistle:!

Kitty Hello

There is a project that tries to implement a script language (GLBasic) within GLBasic. It might be nice to have that every now and then...

GLBasic is not slower than Blitz. If it is, you probably do something wrong.

mahan

QuoteReally: I'm a professional C++ programmer in my full time job. I really know C++ and I'm fast with that. But when it comes to programming games, I stick to GLBasic because I'm much much quicker with that.. OOP starts to get interesting for large projects like Corel Draw.

When I spoke about speed in my reply above I was mainly talking about execution speed. (not the speed of development). When it comes to development time I agree with you that GLBasic is probably much faster when you write games compared with using most general purpose languages and start adding graphics/sound/physics-libs to that.

While I respect your opinion that OOP first becomes interesting in larger projects, I don't agree. In GLBasic you have a typical procedural language that supports structs (records). In my opinion you get advantages right away if you start to group functions together with the structs they operate on and generally modularize the programs so that you do the right things, and change the right data, in "the right module". That way you get programs that are much more manageable and you know where to go (in the code) to change something without the rest of the program getting too affected. Pretty much "light encapsulation" so to speak. I'd go so far as to say that once you split your source-code of a project to two files, you probably start to benefit from OOP-principles.

And that's why I made the little test-demo with the callback based "events", since they help when doing encapsulation, i.e. a module can allow other modules to register event-handlers, but does not need to know why or what those other modules want to do when the events are fired.

PS: My full time job is also in development (Delphi/C#/Java), but I love a little variation in my past time so that's why I recently picked up GLBasic to play around with. :)

com_1

Maybe I am wrong words or google poorly translated, not in this case. (not important)

When I said that GLBasic slower than BlitzBasic, I had in mind the following.

Printed(build) code on GLBasic sized - 2000 of commands. (for example)
Press F5 and you can go to drink tea.
BlitzBasic same contrast, makes it as a scripting language - very fast. (seconds)

GLBasic - so(also) good, why should it continue to be modified.

Why not build another version GLBasic, coordinates would run as fast as the scripting language well or as BlitzBasic ?

doimus

Quote from: Kitty Hello on 2010-Apr-29
There is a project that tries to implement a script language (GLBasic) within GLBasic. It might be nice to have that every now and then...

Yes, PLEASE!  :good:
That would be most useful for large projects with lots of data involved. Like when you got a RPG with countless characters, statistics, thousands and thousands strings of dialogue etc. When balancing such game - it's very tedious to recompile every time you change character stats for example.
With scripting, all that is easy as a cake.

Kitty Hello

Why don't you read these strings from a file at runtime?

mahan

I agree with Kitty:

I mean to take the absolute opposite, it's theoretically possible to encode all images/textures/levels/maps as DATA-statements and include them in the compile also, but most people would think that is outright silly :)

I.e. the idea is that you compile your game-engine as a .exe, but all the config-, game- and meta-data is loaded from text-files (or even an local SQLite DB or something) by this engine as needed.

doimus

#13
Quote from: Kitty Hello on 2010-Apr-30
Why don't you read these strings from a file at runtime?

Strings were just a simple example. Real benefits would be from transferring some computations from compiled to scripted language.
Like when working in multi-person teams: designers can tweak the game data in script without messing with compiler and possibly breaking the code.  AI programmer can tweak the scripts in real-time and see the results on screen almost immediately.
In the mean time, lead programmer can do whatever he wants with the graphics code for example, not caring a bit what designer and AI guy are doing.

Quote from: mahan
I mean to take the absolute opposite, it's theoretically possible to encode all images/textures/levels/maps as DATA-statements and include them in the compile also, but most people would think that is outright silly :)

That is opposite, but great idea as well! It would be nice if GLB had a feature to include everything into a compiled file. While the scripting approach is good for bigger games/teams, compile-everything-into-exe is great for small games. I've got a folder with tons of single-exe indie games I downloaded from the web through the years.  Love them as much as I love Lua-scripted Baldurs Gate. :)

mahan

Quote from: doimus on 2010-Apr-30
That is opposite, but great idea as well! It would be nice if GLB had a feature to include everything into a compiled file. While the scripting approach is good for bigger games/teams, compile-everything-into-exe is great for small games. I've got a folder with tons of single-exe indie games I downloaded from the web through the years.  Love them as much as I love Lua-scripted Baldurs Gate. :)

I'm pretty sure we are talking about completely different things:

What I presume you argue here is that it might be good if the compiler is able to include resources (binaries) inside the produced .exe-files in a manner where they can be easily used by the .exe itself, so the .exe in a way becomes self sufficient. I think this idea is interesting. sidenote: I have a license for a program called molebox that does exactly this kind of packaging for win32 .exes.

What I on the other hand was talking about in my previous post was a theoretical way of encoding all images/textures etc. as pretty much data statements in the source (i.e. "Image1.bmp: DATA <pixelvalue1>, <pixelvalue2>, <pixelvalue..n>") which is silly as it would require the compiler to parse wast amounts of extra (probably machine-generated) source, in addition to the actual program logic.