BASIC

Author Topic: GLBasic and a few OOP-like features:  (Read 5256 times)

Offline mahan

  • Mc. Print
  • *
  • Posts: 19
    • View Profile
GLBasic and a few OOP-like features:
« on: 2010-Apr-27 »
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)

Offline Schranz0r

  • Premium User :)
  • Administrator
  • Prof. Inline
  • *******
  • Posts: 5014
  • O Rly?
    • View Profile
Re: GLBasic and a few OOP-like features:
« Reply #1 on: 2010-Apr-28 »
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 1700 @3.9Ghz, 16GB HyperX Fury 2666Mhz Ram, ASUS ROG GTX 1060 STRIX 6GB, Windows 10 Pro 64Bit, MSi Tomahawk B350 Mainboard

Offline mahan

  • Mc. Print
  • *
  • Posts: 19
    • View Profile
Re: GLBasic and a few OOP-like features:
« Reply #2 on: 2010-Apr-28 »
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 :)

Offline Kitty Hello

  • code monkey
  • Administrator
  • Prof. Inline
  • *******
  • Posts: 10697
  • here on my island the sea says 'hello'
    • View Profile
    • http://www.glbasic.com
Re: GLBasic and a few OOP-like features:
« Reply #3 on: 2010-Apr-29 »
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.

Offline com_1

  • Mr. Drawsprite
  • **
  • Posts: 80
  • no comment
    • View Profile
Re: GLBasic and a few OOP-like features:
« Reply #4 on: 2010-Apr-29 »
>>  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 ?

Offline bigsofty

  • Community Developer
  • Prof. Inline
  • ******
  • Posts: 2613
    • View Profile
Re: GLBasic and a few OOP-like features:
« Reply #5 on: 2010-Apr-29 »
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)

Offline gigios

  • Mc. Print
  • *
  • Posts: 36
    • View Profile
Re: GLBasic and a few OOP-like features:
« Reply #6 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:!

Offline Kitty Hello

  • code monkey
  • Administrator
  • Prof. Inline
  • *******
  • Posts: 10697
  • here on my island the sea says 'hello'
    • View Profile
    • http://www.glbasic.com
Re: GLBasic and a few OOP-like features:
« Reply #7 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...

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

Offline mahan

  • Mc. Print
  • *
  • Posts: 19
    • View Profile
Re: GLBasic and a few OOP-like features:
« Reply #8 on: 2010-Apr-29 »
Quote
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.

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. :)

Offline com_1

  • Mr. Drawsprite
  • **
  • Posts: 80
  • no comment
    • View Profile
Re: GLBasic and a few OOP-like features:
« Reply #9 on: 2010-Apr-29 »
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 ?

Offline doimus

  • Dr. Type
  • ****
  • Posts: 284
    • View Profile
Re: GLBasic and a few OOP-like features:
« Reply #10 on: 2010-Apr-30 »
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.

Offline Kitty Hello

  • code monkey
  • Administrator
  • Prof. Inline
  • *******
  • Posts: 10697
  • here on my island the sea says 'hello'
    • View Profile
    • http://www.glbasic.com
Re: GLBasic and a few OOP-like features:
« Reply #11 on: 2010-Apr-30 »
Why don't you read these strings from a file at runtime?

Offline mahan

  • Mc. Print
  • *
  • Posts: 19
    • View Profile
Re: GLBasic and a few OOP-like features:
« Reply #12 on: 2010-Apr-30 »
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.

Offline doimus

  • Dr. Type
  • ****
  • Posts: 284
    • View Profile
Re: GLBasic and a few OOP-like features:
« Reply #13 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. :)
« Last Edit: 2010-Apr-30 by doimus »

Offline mahan

  • Mc. Print
  • *
  • Posts: 19
    • View Profile
Re: GLBasic and a few OOP-like features:
« Reply #14 on: 2010-May-02 »
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.