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

To be honest not worthy dedicated post after such time, but editing my last post also wound't be fair if someone is looking for updates on this.
It look's that I fixed of one nastiest bugs that I wasn't able to diagnose from long time. Due to incorrect process/thread handling on my side (during GLB project compilation), the editor was freezing after system events that were affecting threads - like hibernating, changing some system settings. Now after few hours of testing different things that previously cause that issue, I didn't encounter such behavior, so I hope that it's fixed. That was main thing that was annoying me in long terms, and it could be deal breaking for others so that's why I'm posting this.
Changes/fix in process handling is major fix in this update, but beside that there are some other small changes/fixes, nothing huge, and I doubt that any additional major change/feature will come now (like code analysis for warnings or something).

Maybe not best place for such offtopic but if any one is wondering about possible other editors to use with GLB, most modern editors use LanguageServerProtocol to support additional programming languages (I highly advise Visual Studio Code, as mature opensource cross platform tool with many editing features). And you would need to write such lexer/parser as this would be the best way to have GLB support in all other possible editors. I looked into LSP docs and I'm terrified :D writing complex lexer to have support for all features like syntax coloring/formatting, auto-completion, function hints would be huge job, so if anyone feels strong enough I wish him luck ;-)

Code Snippets / Re: Load data from memory
« on: 2021-Oct-20 »
Interesting secret, if you have more of such, don't wait to share them :D

Off Topic / Re: Steam Deck
« on: 2021-Oct-20 »
Im trying to keep an eye on Steam Deck, and I like current Valve approach - clarity, like in their last video Steam Deck inside
Spec wise its good enough, in GPU terms maybe base PS4 power in handheld, even pure TFlops are showing that's more like Xbox One, but there is difference in architectures: GCN in XOne/PS4 vs RDNA2 in Steam Deck, and between those architectures there is like 40% real world performance difference (DigitalFoundry on YT did some good test around AMD GPUs before current gen consoles arrived), RAM and CPU are also nice. Just saying if it runs new Doom in 60fps I have nothing more to say :D And people are waiting also for such handheld as it quickly sold out, new bunch will be available in what 2Q of next year so..

When it goes to GLB, couple years ago when Steam OS 1.0 arrived I checked compatibility, and main issue was that GLB was using older SDL 1.2, and that OS shipped only with newer SDL 2.0, so you needed to manually download all additional libraries (also for sound), I'm don't remember how that ended for me cause most likely end-user would not play around for one hour to download some stuff for himself. True question is now, what libraries will be included in Steam OS 3.0, and what are current requirements for GLB to run on Linux - is it already on newer SDL 2.0? Out of box support for this OS would be very nice, and allow more visibility on Steam. That's about native support, I didn't test Proton itself, but it looks that very compatible software and should run GLB apps.

Next thing is games compatibility with Steam Deck, few days ago Valve published some docs on that on partners page: Steam Docs
Nothing crazy, game must support game controller (and show proper icons), work on 720p resolution, no small fonts (like 9px size, preferred 12px), if game needs keyboard input (for player name) use Steam API/your-own virtual keyboard and so on, don't see any issues for GLB in this matter. I will check what's new in latest Steam SDK packet to add possible needed functions to my wrapper.

From couple of years that trend for dedicated handheld devices is getting stronger, previously beside Nintendo/PSP there were only retro emulation consoles but they weren't such widely available (GamePark, Caanoo etc.), now there is so many of them (retro consoles based on Arm), and from times of first GPD such portable pc's are also more popular (AyaNeo, OnexPlayer), but never such huge company like Valve were involved into this, that's good, and should have impact on competition on that market. On customer side looking for handheld, price is always some kind of barrier because let's say 500Euro doesn't sound cheap (but considering it capabilities it's fair price), and 200Euro for Android based retro console that can only play emulators (there is so many of them right now) isn't so good as 50Euro for PSP or 100Euro for PS Vita that's perfect for playing dedicated games and most emulators. But market still lacks cheap x86 handheld, imagine 150$ device that could play older games from X360/PS3 era and indie games, that woudn't require most powerfully hardware just newer production process and low end parts, maybe someday there will be device like this, it would have really huge market of possible clients. When talking about indie/homebrew, I can't count Switch, it's popular of course but, that is closed ecosystem console and big N doesn't like homebrew, is blocking unofficial ports from other systems, blocking YT materials that are showing such and so on, and dedicated games from normal consoles are highly lowered back due to console power, but let's don't deep dive into that, that's one of reasons why Steam Deck gained so much in many eyes - open for AAA and indies powerfully and compatible device.

Off Topic / Re: A Pico-8 Like thing in GLB?
« on: 2021-Oct-20 »
I know that thanks to easiness Pico-8 is quite popular, and good for introducing programming to kids, but if I understand correctly biding script language to core GLB isn't enough, you would need to have small 2d engine/suite to simplify everything, to have commands like LoadBackground(image.png), ShowBackground(), LoadUnit(player_sprite.png), and so on available in simple way in some kind of shell called fantasy computer, that would have also built-in features like sprite/map editor and so on. This itself would be pretty large project additionally beside core GLB, maybe someone is already working on something like this or you may start such thing ;]

Announcements / Re: New BETA
« on: 2021-Oct-20 »
ojoj :lol: Couple months away from GLB and I forgot such basic stuff ;/ Let's assume that there was no such question heh
New commands can help achieve some interesting font effects, will have to try them out someday :]

Announcements / Re: New BETA
« on: 2021-Oct-19 »
Nice to see something new, may be usefully :]
I was playing around with some stuff and I think that latest versions have some curious bug :( if you use "SETLOOPSUB" for mail loop you can't move app window around (not fullscreen mode), and trying to do that will hang the process :/ Even this simple code will have such issue:
Code: (glbasic) [Select]
SETLOOPSUB "main_loop"

SUB main_loop:
  IF (KEY(01)) THEN END // if escape key then end app
When Debug is enabled you just can't move the window, but app will still work ok. When using do/loop as main loop with sleep there is no such problem. Checked on Windows 10 (didn't test on other pc, os version), can anyone verify that?

Pages: [1] 2 3 ... 26