Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - dreamerman

I completely forgot about Python requirement, but wasn't it included with older (v14 / v15) instllation of html5 target, hm not sure about that. Any specific Python version is required, like 2.x or newer 3.x?
Good job for testing this, few new question comes to my mind, for example what about simple OpenGL inline like glTranslate etc, will something like that work in WebGL?
It would be great to see additional platforms as such DLC, Linux should be first.
Sadly there is not so much people that likes such small 2d puzzles, people prefer something more artistic driven - like 'The Witness', or it's just rather not popular at moment.

Thanks, to be honest that main menu should be animated/interactive in a way that would show how each game is looking, but this would be just to much work for something like this. But if I will make some 'Action Pack' that would be preferred way to make main menu.
Yes all games are in one exe/project, as those are small games that's not an issue, of course some games have dedicated variables, but most things are shared like map/board structure.
main loop is something like this:
Code (glbasic) Select

do UI stuff (handles inputs, events, drawing both UI and game canvas)
if stage = game_1_
do game_1_logic (AI, tiles animations)
elseif stage = game_2_
do game_2_logic

similar for user input, proper click/key handling function is called depending on game.

Progress with current maze mini-game.
Porting maze generation code to GLB finished, core board generation is done, but most functions like mouse/touch/key events, undo, needs coding/tweaks. 3D maze generation is working nice, not sure about texturing scheme I should use for it, will play with controls for this game mode, now it looks like this:
Sorry for late reply, there were some newer topics about HTML5, generally for me it always had some issues, tutorials and other such small things were compiled ok, but normal projects, with OpenGL inline had some issues, from v16 HTML5 looked broken for me completely, scripts were based on older emscripten and there was some version / arguments conflict.
I don't have HTML5 dlc for current GLB version, so can't test anything.
HTML5_WebGL was referred target as it supports more advanced rendering routines.

What file size has that *wasm file?
Generally browsers will not launch wasm normally, you need some local webserver to make them available (security reasons), one of most popular is XAMPP, if wasm file is good, put it to local server htdocs (or whatever directory for document will be called) and run it with something like this: "localhost://hello_world.wasm"
No idea what with that media packing error that you got.
Linux was one of targets for previous GLB versions, and should be possible, may require some changes/updates in compilation parameters, but more important would be Steam OS 2/3 support without need to install additional libraries.
MacOS even without official AppStore also would be nice - Steam is enough, not sure what are restrictions on OpenGL emulation on M1/Arm devices.
I will patiently wait for any info about this ;)
Off Topic / Re: RIP Oli Frey
I looked at some of his work, and those magazine covers look great, true artist. Covers of many other magazines where copy/paste or simple reworks from official game art, even years later.
GLBasic is using 'well estabilished' libraries, the only way that 32bit target would become obsolete with them is when future versions of GCC would have only 64bit compilation on windows so that would affect also GLBasic, but I highly doubt that, at least for couple years, specially as that such toolchains (GCC) are used also for compilation on some embedded, legacy or special devices (so compatibility is important in terms of target architectures). Even if possible future GLB version will have only 64bit target, most likely you will be also compile same code with older versions just for legacy devices, so don't worry about that.
You raised interesting topic, and it's advised to target 64bit first, but include 32bit exe for legacy devices/as fallback if its possible.
Ah yes, it must be called from inline so arguments have proper types, but it should compile without problems, I've pasted it into your project at the end of *_OGL file and it compiles properly. I'm using it in this way:
Code (glbasic) Select
// put Steam Image from img_handle to GLB sprite with specified ID
// posy -> needs to be calculated to OpenGL notation - from left bottom corner upwards
FUNCTION putSteamImageOnSprite%: img_handle%, sprite_id%, posx%, posy%
        uint32 cwidth, cheight;

        SteamAPI_ISteamUtils_GetImageSize(si_steamutils, img_handle, &cwidth, &cheight);
        //printf("image size: %1d x %1d \n", cwidth, cheight);
        const int cSizeInBytes = cwidth * cheight * 4;
        uint8 *pavatarImage = new uint8[cSizeInBytes];
        SteamAPI_ISteamUtils_GetImageRGBA(si_steamutils, img_handle, pavatarImage, cSizeInBytes);
        FastMem2Sprite_uint(pavatarImage, sprite_id, posx, posy - cheight, cwidth, cheight);

        delete[] pavatarImage;

main difference to your code is that start x/y position to paste image, nothing more, and you can add that to glTexSubImage2D call without other modifications, for me it's sometimes just easier to use inline like this when working with Steamworks.
As this function is fast and user avatars are small there are no visible slowdowns when they are fetched and pasted into larger sprite.
Don't feel bad, sometimes I just overcomplicate and write something confusing. :D

A) just wasn't sure what GLB Integer type are in reality (I should look into the source :D), just remembered that (maybe in some other Basic language) some built-in type could have different bit width, and that stuck into my brain :giveup:

B) really not an issue, one pre-processor command will help with this

C) sadly, that's why I suspected :( Thanks for clarifying that.

D) + E) Yes, you are right with explanation, here my doubt raised because in original C++ method that I saw/am using pixel array is also unsigned char type, so one element is 1byte (each ARGB as separate array element), glb ints are 4bytes (and contain whole ARGB color) so you don't need to use multiplication in that formula to get proper address. That's why I also worried about (A), but it's all clear now.

my modified versions looks like this, full inline:
Code (glbasic) Select

int FastMem2Sprite_uint(unsigned char *pixels, int sprite_id, unsigned int posx, unsigned int posy, unsigned int width, unsigned int height) {
    int tx_id;

    tx_id = get_sprite_texture(sprite_id);

    // code from:
    // flip image
    const unsigned int stride = width*4;      // 4 bytes per pixel
    unsigned char* row = (unsigned  char*) malloc(stride);
    unsigned char* low = (unsigned  char*) &pixels[0];
    unsigned char* high = (unsigned  char*) &pixels[(height-1) * stride];
    for (; low < high; low += stride, high -= stride) {
        memcpy(row, low, stride);
        memcpy(low, high, stride);
        memcpy(high, row, stride);
    // end flip image

    //const void* low1 = (unsigned  char*) &pixels(0);    // not needed
// bind this texture to gl context
glBindTexture(GL_TEXTURE_2D, tx_id);
// change the image pixel data for the bound image
glTexSubImage2D(GL_TEXTURE_2D, 0, (int)posx, (int)posy, (int)width, (int)height, GL_RGBA, GL_UNSIGNED_BYTE, &pixels[0]);

Again both functions are great, and FM2S is really handy as it allows to paste one image into specified region of larger texture, so not only 1:1 conversion are possible.
GLBasic - en / Re: OPENGLES
I'm not expert at that but from what I know, main difference is that OpenGL ES has fixed pipeline rendering (that GLB is using) and in ES 2.0 everything is programmable by shaders, so even for rendering simple 3d cube you need to use vertex and pixel shader fragment programs, this would either require rewriting part of GLB engine or add some translation layer or default shader code to at least have 2d rendering working (this would be simpler as basic shaders are enough), many 3d GLB functions such as lights/shadows/specialfx would require more work.
The lack of shaders on Android in GLB (due to ES 1.1) may be annoying as they are handy for some effects like realtime 2d mirrors, drawing filters that emulate older devices/consoles, and other - like using one base sprite with colorkeys that are switched to draw units for different players or whatever.
To be honest, last couple months I only fixed some small bug in game, and apart that I didn't have time to do proper coding ,specially in GLB :/ , just recently I played with maze generating algorithms in JavaScript. Now I will port it to GLB and make some 'game' from it, still I need to write some crazy code to generate 3d cube maze from prepared 2d arrays :> Not sure what later, I would like to finish that Solomon's Key clone, or at least push it to point that only sound and pr/steam/translation in missing, as I could do proper alpha testing in such case.
I'm waiting impatiently to see Yours projects :P and really any GLB project ;)
Great work, thanks for sharing  :good:  this is something that could be used to create interesting 2d effects along shaders.
I'm using your FastMem2Sprite in my Steam API wrapper (little modified) for copying users avatar pictures to sprite and that's why I had some question about code responsible for flipping image. In your code one of lines is:
Code (glbasic) Select
unsigned char* high = (unsigned  char*) &pixels((height -1) * width);
in c++ examples the last variable isn't 'width' but 'stride' -> 4*width, and I was wondering why it's working here, then looking at rest of code reminded me that as function argument you are using glb int array without casting it to 'uint char/byte'. This raised another question, glb int in 32bit are 4bytes, but in 64bit are they 4 or 8bytes? But after compiling to 64bit win it looks that they are still 4bytes and code is working without problems. One thing here, not sure if
Code (glbasic) Select
typedef unsigned int size_t;
is really needed, it will compile without this in 32bit, and in 64bit it will give an error as size_t is already defined somewhere in c++ libs, it would be good to have at least some check here.
One thing that gave me a headache (as I forgot about it), was that 'power of 2 requirement' for texture size, I switched texture for some 720p image and it wasn't working, it took me couple minutes to figure out that it needs to be ^2 :D but that's really not an issue, as for any tricks we can use larger sprite/texture.

And thing about OpenGL ES, yeah unfortunately it lack's glGetTexImage but similar result could be achieved with glReadPixels like in this code:
did You checked something like this? I don't have Android toolset now, so can't play with this, but one of most desired use case would be on Android to simulate some shaders that are not available in GLB on android.

Ah, I would forget but here are result's of this benchmark on old i5-4300u w Intel HD 4400 iGPU:
FastS2M + FastM2S -> 115cps
GLBS2M + GLBM2S -> 9.8cps
FastS2M + GLBM2S -> 10.7cps
GLBS2M + FASTM2S -> 54.5cps
With such speed it could be used to some real-time effects on smaller textures.
There are more of them but quite similar, some completely inefficient, and some have slightly different use cases like mazes on infinite maps, but it's good to see how they works and adopt something from them to proper game oriented code.
Of course more interesting are different shapes of cells and grid itself, for example circular maze - polar grids, but this would require vector drawing routines, I know that there was some small lib for that here on forum, but at moment I've other priorities. Yet I will try to add some simplified maze generation routine for 3d cube, it shouldn't be hard.
Just for testing I have added modified version of Prim algorithm to generate more straightforward maze - tiles can be either empty/passable or blocked, it may simplify uses in some cases and shows how easily it can be modified.
Another thing that could be interesting for more complex algorithms are tunnels, yet it would complicate drawing, as such should be easy to differentiate from dead ends - just matter of proper sprites.
SmileBasic looks like something interpreted, and from what I see it can't produce standalone apps, only launched from app player. I'm more curious what's the current state of HTML5/JS development on Switch, either pure canvas or WebGL / WebAssembly based, as JS is sufficient for most 2d games. Yes Nintendo has more closed platform than others, and surely game needs to be accepted by big N, for example on Xbox Series there is an 'dev mode' on normal consoles that you can use to port some games, and most likely they don't have such rules/requirements for games.
Of course it would be great to have Switch as additional platform on GLBasic, but this would be surely a lot of work, and NDA implies some restrictions for all such tools.
Rather small update than some super changes.
'BR Logic Pack' started as 6 puzzle games pack, now there are 9 games, and I plan to add at least 2 more.
3 'new' games are:
- Pixel Village - build walls and roads with nice pixel based sprites,
- Dungeon Slider - move wizards in dungeon and collect potions,
- match 3 - classic game with some variations,
- additionally few other games got new playing modes,
Game is also available on, You can download and check it out for free, Steam version will get new additions earlier and currently supports achievements and leader boards (for now only sends user score, but all code for online high score is already in game and awaits for larger update).
trailer for current version:

Current main project is clone of Solomon's Key game with rather old school pixel-art graphic (based on itch / devmarket assets due to limited founds :D), many things are done: most graphics, core mechanics, menus, Steam achievements + leader boards, map editor with sharing levels online (classic web-based not Steam Workshop), some requires more work: additional game modes, boss logic, atm. has no music/sound and needs some polish before I will share proper gameplay video.

Another large project that's currently in limbo is an 2D RTS game (viewed from side, not top), won't say to much but I have basic prototype, and final product will be interesting. Have some nice ideas for it but, this would require redesign from ground to use threads, remaking my gui system, polish pathfinding and so on. Will get to work on this after finishing current things. Don't wont say to much as it's still early stage.