Menu

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

#31
There should be no problem, if it requires to use some specific OpenGL extension or API - that could be done in Inline.
In core GLB is fast enough to render separate images for left & right eye, so I'm looking forward to any info about this.
#32
Music in current form is a troublemaker, it's sufficient for small demo or prototype, but not advised way to play music in proper game.
Music subsystem doesn't cache files, so PlayMusic loads file each time, that will cause stutters - it will vary depending on computer, but it's never good thing. It should be reworked to allow similar usage as Sound subsystem - multiple music buffers/streams - but with proper music files, load all music in game loading stage, then just play selected stream. Special effects for music files like 3d or something aren't needed.
There is a simple workaround for this for example using SDL2, i posted an example somewhere on forum, so that should work on SteamDeck.
Reworking music subsystem to any other lib (bass, fmod, soloud etc) would be nice, breaking compatibility for older GLB versions may be issue for someone, but focusing on modern platforms, and proper functionality for games should be more important.

Changing all music to sound file types - *wav isn't best solution for all games, if you have more music tracks or they are longer the output on file size will be to high, not even that, loading time will be longer than it should be for such small game, for me it's mitigating sense of using optimized tool like GLB.
Greedy Mouse still loads fast, but does it have 1 music track or more?
#33
Steam OS is using Proton for translating/emulating windows apps, I know that even AAA games are working great with it but native binary is just straight better, and there always can be some possible issues or restrictions with Proton.
To be able to properly (or safely) use SteamAPI (like virtual keyboard) or SteamDeck specific controls Linux build will be most likely required.
Next thing is that other companies may use SteamOS for their handheld devices (Ayn, AyaNeo etc), but not all will be so powerfully, and beside that, native game will be more optimized and won't drain battery so hard as emulated one.
And beside SteamOS there are other Linux distributions, and not everyone want's to configure additional tools like Proton to play some particular game, so normal build option for them would be very welcome.
#34
Yeap coming back from a longer break can be hard, so don't rush and work it slowly to get back to proper state of mind.
My advise is also document each day progress in some way - few sentences in notepad, and more important proper TODO log, with even small task that needs to be done, bugs to fix, new ideas etc. - with their current state. This way is much easier to come back faster after some break.
I always have issues with proper documenting the code, as 'nah I will remember about that' always come to my mind, and later you can guess how it ends :D
#35
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.
#36
@erico
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.

@loftcat
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
[...]
endif

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:
#37
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.
#38
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 ;)
#39
Off Topic / Re: RIP Oli Frey
2022-Sep-20
RIP
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.
#40
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.
#41
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%
    INLINE
        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;
    ENDINLINE
ENDFUNCTION

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.
#42
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

INLINE
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: https://codereview.stackexchange.com/questions/29618/image-flip-algorithm-in-c
    // 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);
    }
    free(row);
    // end flip image

    //const void* low1 = (unsigned  char*) &pixels(0);    // not needed
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
// 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]);
}
ENDINLINE


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.
#43
GLBasic - en / Re: OPENGLES
2022-Aug-20
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.
#44
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 ;)
#45
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: https://stackoverflow.com/questions/53993820/opengl-es-2-0-android-c-glgetteximage-alternative
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.