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.

Messages - dreamerman

Pages: [1] 2 3 ... 26
Steam version contains also standard executable that doesn't require Steam to run in background, this is that file: "...\Steam\steamapps\common\GLBasic_SDK\EditorE.exe" ;)
Ah so there is no option to run x86 Windows in such virtualization machine? I didn't touch them in a long time, but they were specially handy in running some old Win95 games :D

Edit: and of course you can use Steam version normally and just run GLB apps directly - not from editor and see if flickering still appears.

Announcements / Re: Manic Miner GLB
« on: 2021-Nov-29 »
Nice retro project, looking at this I really feel old vibes but don't get me wrong I'm glad that those times are gone :D consoles were better with hardware sprites, palette switching and so on, best 2D for computers were later during Amiga 500+ and competing Atari times. But from technical aspect looks that it's faithful to the original.
I hope that there is no copyright restrictions on such old thing, as you could put it on even as free project to get more feedback. If you are working on something else don't hesitate to share on forum ;]

Your site is down, but checked demo attached in first post, nice old school gameplay there :]
I went to see source, and wow, more than 100 files, looks that You have separate file for every enemy type, game mechanic and so on, interesting, I prefer to have for example one file for all AI, but whatever suits you, specially that code is nicely structured and formatted, despite using DrawAnim it isn't demanding like many other small indie games (GLB power). Played 3 levels, sun can be annoying, there are some hit box/collision problems in this version (sun hit me even when crouching and he is 2 tiles away), level 3 is crazy but funny :D
Most notable suggestions is give option to change video resolution - even basic 2x/3x scaler or something would be nice, and give option to use WASD keys to move, as arrows aren't always best for this - laptops.
Don't forget to upload newer version and share changes, but what's most important put this game on ;)
btw. nicely animated fox.

Windows 11 has some issues so I would not use it for such thing for moment, Win 10 would be better imho. I don't know what gpu configuration options Parrarel has, so hard to say, as generally driver issues can be really tricky.
One thing that I can advise is running standalone GLB version (both editor and compiled projects) - not launching it from Steam, as  Steam attaches overlay for everything, this also can cause some problems even if it's not properly displayed.
Sadly Apple restricted new iOS/MacOS apps to use Metal API, I'm curious if currently OpenGL apps could be compiled to MacOS as Steam is available there so can be used to distribute games on this platform. HTML5 target is also a solution if it handles all GLB functions properly. Please update this topic if you found anything new, specially related to M1 macs, as this architecture change will evolve in future, on PC market we are years before any ARM revolution, but node shrinking and new technologies still will give nice improvements.

3D-snippets / Re: SGEngine
« on: 2021-Nov-29 »
Very nice, clean coding and well structured. Looks very easy to use. Checked several things, they are working without issues even on iGPU.
I have some tech questions, as always :D I'm curious, as Irrlicht could use several render API's (OGL, DX, software), You most likely are using OpenGL, are you creating another OGL context or using that already made by GLB? Does Irrlicht have now something more advanced than basic collision detection? (years ago they wanted to include some physic lib like Newton or Bullet if I remember correctly).
Such engine gives much more opportunities for more advanced 3d from start, so it gives some nice possibilities, one thing that is how portable this will be, for moment GLB main platform is Windows, but what about Linux (most likely should be simple and just use other headers), HTML5 (this may be tricky). Still current state of Proton and x86 emulation on MacOS can mitigate possible problems with this. Really nice to have another rendering back-end, even If now I would use it just for testing some things.

Thing about motivation, yeah, specially for larger project where so many things need to be done it sometimes hard, but I'm glad that you found perseverance to finish this ;)

Sadly to hear that, Covid hit us hard, I hope that all goes for the best for You :good: But back to topic.
I wasn't aware that so many countries doesn't have agreements with USA about avoiding double taxation, in this situation it really could be better to publish there using someone help (from country having lower tax), as Steam gives such option as I understand, your account would have restricted access to that particular project, and would be able to see all Steamworks/financial info. Still for such small games best idea would be to bundle them into 3-in-1 pack or something, fast, small pixel arcade games pack or whatever. If they would have such fancy 3D effect like SnooPI was talking about, they would have much higher chance to earn something.

Checked that zx game project, looks nice, and well documented in that forum thread, you nicely describe every step of working on it. btw. thanks for mentioning that MPAGD tool, I know someone that will be interested in it :)

Wasn't aware of OpenMP, very handy for splitting huge calculations from one loop to multiple cores without bothering to much, could use that in something else.
Yeah I know parallel threads are tricky, specially for such things that are shared by different threads, good design will be crucial to get it working properly and efficiently, this is some kid of final goal, most likely at start I will stick with single thread for some time (do most game logic to get working demo or something), but MT would be final goal. Do you still have this example project with lib somewhere?

Bumping, attachment isn't available :-(
As this is old post from few years back, and we got some core changes, like GCC behind GLB was updated, new platforms, and something regarding this topic could change as well in that time. So my question is: what's the current best multi-platform way of doing multi-threaded app with GLB - that would work for Win/Linux and Android. This lib, C++ inline with <threads> or SDL_threads.
And a general question, any one used threads in GLB in final/released product, or have additional examples (to just bundle it all up), is aware of any special restrictions, or have hints and tips for using multi-threading in GLB? I know that core drawing/media functions needs to be used in main thread only, my additional threads would do pure calculation stuff like pathfinding/collision checking (with use of Timer/Sleep functions and etc).

Erico I always liked Your art style, those pixel chickens are really superb :D Great use of limited size/palette and animation frames.
Different backgrounds/level layouts are always welcome to give some variety in gameplay.

Talking about monetization aspect, can always give some income, but on Steam there is so many games now, and it's just hard to get noticed with small games that doesn't have some special feature. Such 3d voxel like graphic could be the thing that would make it more interesting visually for streamers that play small party/versus games. Or maybe have two rendering modes 2d and 3d with option to switch with one key, but that's something to consider after dealing with all core stuff.

I'm using this dll method from more than year in my game for user stats/achievements and they are working without issues (at least didn't notice any and no user complained about that) so I think that's good enough for a workaround method :]
This update comes with many added functions and handlers for Steam API callbacks, but only those that most likely will be used in any GLB made game. Some changes in core functions, but most important is leader boards support added, partially tested, due to how it works, I will verify everything after adding Steam Leaderboards/Highscore system in my next project.

Module updated to use latest 1.52 API interfaces, generally most changes in Steam API were made to add support for Steam Deck. About that thing, controller support in GLB is good out of box (even get controller names), vibration can be added with SDL inline so I don't see reason to bother with Steam_Input interface for now, specially that I don't have any gamepad/controller at moment :/

GLBasic - en / Re: new HTML module on steam
« on: 2021-Oct-27 »
Hey, partially answering to your question with some workaround, Steam GLB version has now non-steam version of editor included (that doesn't require to be launched through Steam), so You can copy "\Steam\steamapps\common\GLBasic_SDK" (EditorE.exe) folder somewhere else to have working backup of v16 that You can use to build app for Android/other platforms.

I'm also curious if that's complete suite or there is need to install additional tools like Emscripten, JDK or whatever, as previously there were some issues with that. Another thing is that PolyVector (batch sprite rendering) / file loading (txt with sprite rect's in atlas file) is supported in WebGL target?

Qedo it isn't an issue with your computer, on my pc FileRequest$ also doesn't work but gives other error 'Access Violation Exception', on both Win 8.1/10, it doesn't work in either debug/release modes, and this only applies to v16 (Steam), same code compiled with v15 works properly and opens popup window. Also I can't get those inline examples working, Am I missing some include files or something that's needed to check this?

GLBasic - en / Re: True Type Fonts
« on: 2021-Oct-21 »
Please dont get me wrong but bug happens to everyone, or I would quote now popular catch phrase "mistakes were made" :-)
If you see that something isn't working as it should/feature isn't complete or something post it on forum, such things could get unnoticed. TTF or custom font face swapping is nice but for simpler multi-language support I'm sticking to sprite fonts - much easier to prepare let's say Chinese buttons for small games without messing with Unicode. TTF also has its place and it's own strength.
One good thing in JS is no compilation time, and instant preview for small things, good way is to write small parts of code in JS to check everything and later translate that to final programming language.

As already mentioned by others, I would use simple array check for map tiles as those are mostly square sized, and rect colisions for all other game objects like enemies/bullets/powerups, pixel perfect collision sound nice but as you already noticed isn't perfect for all situations :) and it's much slower if you will have dozens sprites to check. Depending on game can be using several smaller rect boxes for collision that would cover most of player sprite, let's say you have top down shooter, you can easilly use two rect for palyer aircraft, one for hull second for wings and that's it.

Just answering if anyone would search for similar topic.

Code Snippets / Re: CUSTOM SHOEBOX
« on: 2021-Oct-21 »
Very nice project, due to previous bugs with GLB shoebox I was looking for possibility to use it in next project, but main issue was that for sound/music it needed to save files on device and was opening them in standard way, so it makes loading times longer when there are many media files :/ (i was afraid specially about Android) And im also not sure how loading from custom shoebox and using Mem2Sprite would compare in terms of speed to normal shoebox. But nevertheless I looked even deeper, in SDL docs you can find function that creates sound/music objects from memory (like Mem2Sprite), but that isn't well documented if I remember correctly so that would be more tricky to do it in GLB. Beside all this it was very promising, and could be even better if additional files encryption could be used apart compressing them as PNG, some kind of password system or byte checks when uncompressing.
Thing about compression, there is minimal zlib.dll version that contains only basic functions for dictionary base compression, curious how this would compare to 'compress as PNG' method. Years ago I made some kind of LZ77/dictionary encoder in FreeBasic, wasn't so good as zlib but still it was only pure Basic code, maybe time to rewrite it in GLB just for fun.
But now with this load data from memory hack you can rework your shoebox to use this trick and that would be awesome, another possible way of protecting/packing files, I would like to see direct comparison to standard shoebox in some game project.
I also don't have AndroidStudio installed currently :D so can't test it that way..

Pages: [1] 2 3 ... 26