I have checked the NEWS on GLBasic but it hadnt been updated since OCT 2016 :bed:
currectæy not much and im persoally have been away quite a bit for various reason. Howover im did do a update to the iOS version recently after that date, so get it combatible with iOS10.
Glbasic is today only require update for eventuelly bugfixes. If you ask me. Howover mod support its would been nice, but its a another story.
Yep, apart from some bugs, which are possible to go around, the core is quite strong and stable. :-*
Spacefractal has done some excellent work on keeping some platforms updated. :good:
Quote from: erico on 2017-May-18
Spacefractal has done some excellent work on keeping some platforms updated. :good:
:nw:
GLBasic have some strong competitors.
If you don't do anything to keep it alive, you die the Blitz3D dead...
I don't know how busy Gernot is, but i see GLB slowly dying! :(
GLBasic need a facelift and some more modern syntax, something like GLBasic 2. :)
Gernot, grab a team and make GLBasic great again! <3
Quote...but i see GLB slowly dying!
I have a bad feeling about this!! :S
Please, do not let dying GlBasic. I have fun doing games!! ;/
I am still developing in GLB because it is great!
I think newbies might be put off by lack of step by step tutorials.
A nice new bootstrap website layout would look nice too.
If Gernot did a campaign for Funding the website I would have no hesitation to contribute - maybe even a Kickstarter (for publicity)
Make the goal low enough to succeed and we could all back it ?
Me too, only coding with GLB.
Newbies will go for the publicity, most likely unite.
Tutorials in video would surely help, but they are not easy to produce (very possible though, it does not need to be pro).
What I truly think we need is more development and showcase.
The website as it is now is fine with me, but that could only be me. If any other major thing is up in production, then I agree a revamp would be key.
GLB II would be a dream come true, please consider.
What we have right now is pretty perfect, needs only some bugs killed. Could be used as a base to a follow up?
I´d sure back anything GLBasic related.
I have coded lots of stuff with GLBasic, not only what I show here, lots more.
The Avocado game is waiting a bit as I´m trying to get government sponsoring for it.
I´m also planning a GLB introduction workshop. Let you know later if it works out.
I´m also working many other little games, like this one here:
Nice lo-fi Burgertime graphics :)
I did a BurgerTime game in 2004 using Blitz.
(https://ia801305.us.archive.org/28/items/super_burger_bar/VirtualBox_IE6%20-%20WinXP_26_11_2015_23_29_59.png)
Sadly the game was quite buggy and although it's online I no longer have the code to recreate and improve it. The game isn't playable on my Win10 machine either (1FPS!).
Mmmm burgers! =D
Seriously though GLB is pretty solid, it's platform support is still second to none. For me, it does what I want and it's fun to use while doing it.
@Ian Price, nice version! I can see your style in it a bit on the gfx.
What are the 6 slots on the top? Power ups? Of what kind?
I´m looking into having 2 or 3 main player that can hit each other to add to the fun and also time the levels, if time runs out, the levels start sinking into the waters, except the base burguer platforms.
@MrPlow, this one here is the lo-fi :)
Gernot might not want to do a GLBasic 2 (as cool as that sounds), as it is so much effort for little benefit (financially, unless it becomes very popular.)
He should consider a community open sourced version, completely rewritten from scratch, with modularity and simplified platform support integrated at a low level. It would be great if each command's code could be separate and independent, with optional code files for each platform, if needed. (Ha, I have no idea, never written my own language!)
The problem with this might be that not many people would contribute (especially if done in C++. C# would be nice. Hey, write it in GLBasic!). It would take a long time, but would be a fun and rewarding experience. Who hasn't wanted to write their own programming language?
Only an hour until lunch! I'm thinking burgers, for some reason. :)
@erico My game did have power-ups (lots of them), but the six boxes at the top of the screen held rainbow coloured gems. Collect all six to enter a special bonus level (like Rainbow Islands). The graphics were all mine, but I've changed palettes and styles a fair bit since 2004.
Why is always the solution: "Rewrite from scratch to get rid of all bugs!" ?
If you rewrite from scratch you throw away all knowledge and fixes to problems and have to do it all from the start again :-)
Obligatory xkcd: https://xkcd.com/927/ (https://xkcd.com/927/)
Yep GLB2 will get rid of all the old bugs and introduce lots of brand new ones :D :D :D
I certainly agree with you 2. Increase what is.
I thought "GLB 2" more like a re-branding if ever needed.
Into the dilema of opening the source, I have doubts it would do much good. The current system is doing ok, but at the same time we only carefully approaching new people to help deving. There are so many variables into count that it is hard to analyse.
I hope to, at same point, add a bit to it and do some new gfx for GLB and probably the site too. An updated showcase made on the front page would also be cool.
But participating in creating a new game engine would look great on your résumé / CV! :P
Really, GLBasic is very close to being complete, with a few bugs remaining.
But it is still a non-OO language. A rewrite could fix that. :whistle:
But...participating on advancing a well established programming language would look even better on the résumé! 8)
About the non-oo I have absolutely no idea, hehe.
the main issue there is also exists other basic like language. Now my Mac is out of service, that means im currectly cannot update iOS version of glbasic (im have still not misgreate to vmware yet, but close). Im have currectly no plans to purchase a new Mac, mightbeen a used one?
Also im should on a point, sooner or later update the Android port to uses the newest or second newest SDK. But Android do still works as intendend, which is most important.
Im do pretty sure you can get source code from Gernot, if you want to fix issues (which you should also let me know). Howover without Headkaze, im could not port glbasic to 64bit at all.
To bring Windows 10 support, the iOS Bridge could been used (which would also been on eventuelly Xbox One).
PS. Even its little bit "old". its still a great language. Also.... Im still use Paint shop Pro 7, which is SOOO old today (but im like it).
This is huge and difficult topic. Many many things could be written, but in shorts, Kickstarter/Greenlight boom resulted in game makers boom, that time they have some crazy licensing like 1000$ for one platform, many good promotion stuffs (advertising / video tutorials / yt panels) form Unity and others and here we are. now most games are made with 3 tools (Unity / UE4 / GameMaker), and normal languages have rough times (also other tools to, where is Shiva3D, Torque, Marmalade ...).
Conclusion:
GLB as game oriented programming language is good and solid, allows for much flexibility to combine 2d with basic 3d for some nice effects, many modules / ready to use examples are on forum, but it requires to write a lot of code, that nowdays only few people want to do.. Yet it wasn't so promoted as other tools, so had lower chance to took their approach in that changing indie dev market - like crowd founding (look Monkey2 / AppGame Tool Kit).
Beside that most important features still remains - easy to learn, really fast (as code is translated to C++), in 2d/simple 3d it's best (game making tools can't compare) what you can get without going to pure C++. You think thats nothing? Try to play some Steam indie games made with Unity/GameMaker on iGPU :D and same games with proper codding would work great on mobiles if they were made with GLB... That's the prize, for speed you need to do much coding on your own. Of course GLB has so some issues with mobile platforms but I hope that they could be resolved (or already are, as I didn't watch Android topic from some time).
Topic is much deeper and everyone has some thoughts. Complete language reqrite would be pointless, as it would require to much effort and competition is really hard, I would opt for fixing eqentuall bugs and keeping current functionalities. And I'm sticking with GLB for current projects, I doubt that will be doing some UE4 based game ;)
I hope that those few nice looing projects that are here on forum will be finished, that would be another good showcase (of course bearing in mind those few games that are already on Steam).
ps. Win10 - UWP is something worth to check, I mentioned it in other topic (https://www.glbasic.com/forum/index.php?topic=10876.0)
GLBasic is great for 2D games, but is lacking a lot of functionality for 3D (stuck with OpenGLES 1.1 last time I checked), so lacks most shader functionality. Also, both 2D and 3D have no physics engine. And it is not an OOP language (debatable if this is good / bad! :)). Multi-platform support is buggy, but considering only a couple of people are working on it, it is actually pretty good.
But understanding this, it still has some amazing strengths.
It is fast, in my testing, as you mentioned.
It is very easy to learn (my nephew had a platformer style game working with almost no programming experience). Who doesn't love programming in BASIC?!
Knowledgeable and helpful forum support (although fairly quiet recently)!
I'd still be using it if it was OOP, had physics, and an up-to-date OpenGL.
I was (half joking) suggesting a rewrite if it could fix the above issues. And not for competing with the other engines, but as a learning experience. (Rather than trying to patch the existing GLBasic code.) Ha, ya it would be difficult - I wouldn't know where to begin!
Quote from: dreamerman on 2017-Jun-16
... but it requires to write a lot of code, that nowdays only few people want to do... topic (https://www.glbasic.com/forum/index.php?topic=10876.0)
I´m not sure I understand this correctly. Any other tool will require lots of code on its own scripting language if one is going to do anything non-crap.
It is for this reason that I prefer a coding tool right away, and once you did some coding/modules, you can recicle them later.
As for people not wanting to do work and expecting a game to write itself...that has always been the case. :D
I agree with most of the points here...
GLB is great, its fast, and like Erico i hate draaaaag 'n drop GUIs with mindless mouse clicks...gimme coding anyday...
I am actively developing on android - and have a few apps in progress...its because of GLB I am in top 5% of Android devs according to Appbrain :)
I just released a little clicker game called Rogue Turret (starwars themed) plays fast and is small download... :) ...thanks to GLB!
Just needs more exposure, some bug fixes, a bit of marketing, carrot-on-a-stick approach to get more devs using it or trying it...
That was my biggest complaint about Unity - too much UI interaction, just let me code, damn it!
The learning curve is huge! Took me years to get comfortable, and I'm still learning.
So over that time I've managed to create my own library of classes to allow me to code my games without interacting in the UI much. My scenes are fairly empty, and I dynamically create my gameobjects at runtime, and add the desired behaviours. Ahh, that feels much better. 8)
The UI-Way ist more efficient, if you managed to deal with it!
Ya, I pretty much learned the UI over the years. I still use it to handle audio and graphics (images, shaders, materials, etc). I gave up on using it for the game GUI, as I kept making changes that I'd have to change in every menu. So I designed a Style (skinning) library, and UI library, so one line of code can place a stylized button on the screen, and handle the different resolutions and aspect ratios. It all depends on the game type, mine is fully dynamic, so mostly through code makes sense. But there's still no option to whip you to keep you motivated! :whip:
Ataribox seens to been somewhat "Ouya 2.0", but with a Linux installed with a AMD installed. Since many of us create retro style games here in glbasic, im think this box could been a perfect match for glbasic and im should ask Atari for a SDK. But howover its not Android, but Linux, so its might take some time me guess. But should not been harder than example raspberry pi, which runs Linux with same CPU.
For me the best game, could been fun to see CatchOut for AtariBox (as a Free game). Its depend controller its plans to use.
Also its could also been a great test console as well (which im eailer used Ouya for when released for Android TV).
Im have contacted and emailed them.
Version 15 seens to been great for Windows, while im have fighted the choopy framerate issue that should not been there in eailer versions and could newer ever find the issue. Me thinks its could been a array issue, but have no idea why.
Howover im do asume version 15 now uses a much newer version of the compiler, which also should help fixing issue like that.
The most odd, the issue have only allways have been a issue on Windows. Newer on Either Android or iOS. Sometimes the frame rate chops in the first 15-30 with full cpu usable then its after fix its self after a while.
very odd currectly the game can slowdown when a gamepad is NOT inserted, but run fine when im insert such a one (its dont matter its a wheel or other).
Its would been nice to completly remove the directx polling, which im guess its cause the slowdown issues, when a gamepad is not detected or as a advanced command line command (-nogamepad).
Hi - Yes I have seen Gamepad or use of GetJoy commands slowing down the windows games hugely.
Obviously a bug somewhere - so this is fixed in version 15?
yes, something like that. Here when NONE gamepad is used, then its run slow, but run fine when plugged in. Also the other way. Its weird, pretty weird.... But DirectInput is Windows only, so its can been why its works pretty fine on other platforms. Im will checks what its do in SHOWSCREEN, since the slowdown happens there.
LOL. Do NOT call any joy commands when a gamepad is not plugged. GETJOYNAME$() is IMPORTANT. This is only took some years and first noticed it now. Its seens the framerate slowdown have finally been fixed.
So you are 100% right, and a fix is very easy too. Use GETJOYNAME before use of a JOY command. Glbasic should have do that automatic for ALL joy commands.
Maybe a silly or crazy idea:
Group up and make a "GLBasic 2" by our own...
Fresh from the start, AND open source from ground up.
We have some really good people in our community, and Gernot can help in his free time if he feel like to do so.
The community can stay here, and maybe grow up.
I love this place and community more then a decade!
Let's give it a new facelift :)
That would indeed be awesome, but a massive, massive undertaking.