What is the most stable version of BlitzMax?

Started by imaginaryhuman, June 16, 2023, 00:35:30

Previous topic - Next topic

imaginaryhuman

Question in a nutshell, if I were trying to make a fairly large desktop app, which version of Blitz (probably NG) would be most stable, reliable, bug-free? (mac and windows)

Midimaster

the one you can find on the BlitzMax homepage:

https://blitzmax.org/downloads




In Discord you can get links to newest release every night. But those releases could contain new unstabil modules.
...back from Egypt

imaginaryhuman

Do people feel that NG is really stable, is it known to be fully bug free or are there are a list/lot of open issues? In the past I had some problems with it.

dawlane

Quote from: imaginaryhuman on June 16, 2023, 02:01:18Do people feel that NG is really stable, is it known to be fully bug free or are there are a list/lot of open issues? In the past I had some problems with it.
There is no such thing as fully bug free software. There are bound to be bugs known and unknown.
And as BlitzMax NG and the modules have many different contributors, you'll never get a definitive list of all issues.
I would suggest that you try another tool for what you are about to undertake, that is well established and has a dedicated support.

Midimaster

The support for BlitzMax NG is awesome today. The new stabil version was published some weeks ago. And there is a team, that immediately care about new issue reports and reacts (often) within 24h.

Old BlitzMax is out-dated and nobody will/can help you, if you find a bug. And new operation systems cause new bugs. Think about the use og "https", which nowadays is standard, but old BlitzMax cannot handle.

If you really would find a bug in BlitzMax NG you can open a ISSUE at GitHub and the deveopers will care. If you are not used to GitHub, you als can post the problem here or in the Discord channel. The developers read both forums and will make the ISSUE report for you. 
...back from Egypt

Pebender

BlitzmaxNG is very stabile for me in Windows10, 
I love BlitzmaxNG.

Derron

If you only use "standard stuff" in NG you won't encounter much bugs. The more "advanced language features" you use, the more likely you might encounter bugs. Some of them will be fixable within hours - others are so "deeply buried" in the code that it is really hard to tackle them.

I compile my game TVTower for many years with "NG only" on all 3 major platforms (Linux, Windows and Mac). Of course people report issues - but in 99% of all cases it is something _I_ (read: the game project) did wrong in the code.


bye
Ron

imaginaryhuman

I'm considering using NG but I also need a couple features. I notice there's support for render textures now, is that pretty stable? Also I need to do some construction of custom meshes with custom shaders, is there a 3D plugin of some kind which does this and works on all platforms... i mean including Metal on Mac where there is no OpenGL support?

imaginaryhuman

Is there any sort of well known successful software created with Blitz, like some significant app or game that's out there? (super skid marks comes to mind etc) but like any major apps that someone is selling through a website etc, running a business based on sales etc?

markcwm

I read on Github that the 0.136 release included a ton of bug fixes, that is the one available on blitzmax.org now, but there is a new 0.138 but I know nothing about it yet. I've tried 0.136 on MacOS and it worked fine at least with what I tried it with.

There is no Metal support currently but there are plans to provide a driver by wrapping bgfx, Brucey and Dave Camp have been working on that (here is the mod I don't think MacOS is supported yet) but maybe someday as Brucey is currently working away on NG.

imaginaryhuman

#10
I see Apple silicon macs still support OpenGL 4.1 .. but it is considered deprecated, and apple may (?) at some point completely remove it. That's the part that bothers me that a user could upgrade a suddenly a new mac or updated OS and then the NG-based software suddenly just bombs out.

Unity3D has this statement: "As a result, we will officially deprecate the OpenGL graphics API for macOS platforms in the 22.2 release, and Unity 2022.2's system requirements increase the minimum required macOS version to 10.14 for both the Editor and the Player. We are going to remove OpenGL support for macOS entirely in Unity 2023.1."

A question that comes to mind then is. ... say I want to create meshes and do texturing and use render textures and custom shaders etc.... for animation purposes, and I currently code it using all these immediate-mode OpenGL commands for example, or use some 3rd party 3d lib, then the NG developers come out with metal support, is my code going to still just work or is the entire graphics code going to be obsolete, and have to completely recode every call to the graphics API? Cus OpenGL commands are not exactly 'standard blitz' code. Will the metal support just translate them or are we looking at a whole new API here?

And is perhaps there source code for the metal api like there is for OpenGL, that could be converted to work with blitz?

imaginaryhuman

Also a separate question on stability. Would it produce a more stable app if I split it into many smaller source files, like making libraries of functions?

Also is it more stable to put almost all functionality inside functions instead of having a large main program? Is there e.g. a potential to run out of local variables at some point, and what happens when it does?

Is there some best practice info/document about how to structure a bigger app in blitz?

Derron

Imports or includes - are a matter of _compilation_ speed - and of course easiness regarding "reusability". When including files you most often have circular dependencies and stuff not correctly decoupled.
Importing solves this - by requiring you to think about such things more properly (in advance).

Stability wise the code will be the same (effectively) and stability depends on your code, not on import/include decisions.



Metal: If you use "sdl.mod" and there "sdl.rendermax2d" (so no longer the original brl.glmax2d or brl.d3d9max2d - and also not their sdl ports sdl.glsdlmax2d etc) then you will automatically gain support for what "SDLrenderer" supports as graphics engine / backends.
Currently this means:

direct3d
opengl
opengles2
opengles
metal
software
(D3D: 9, 11 ...)


Render2Textures: Where is a new branch of me (and col/dave camp) which fixes some issues with the current revision of our render textures code. We simplify some stuff, extend other areas (like new overrides) and fix issues (think we had issues with viewports in the textures - or the matrix used for scaling/viewport/rotation/...).There is one thing NOT being done correct in the "brl" graphics backends (and their sdl ports) - and this is premultiplication of alpha. Prior canvases ("backbuffer") were solid and thus calculation of things like "drawing a semi transparent image on it" was simpler. You would simply "mix" the colors according to the alpha of the "to draw image".With transparent render targets now - things are no longer correct.
There you need to do "premultiplication" (each image, texture... you render would need to incorporate the alpha channel in their color rgb channels already).SDLRenderer (so sdl.rendermax2d) does all of this automatically for us - so this is the only one doing it correct for now. In all other max2d-backends you will encounter a bit "darker alpha-shadows" - means in most cases you will not see the issue, it is just ... not correct :)

As said - use sdl.rendermax2d and you have Metal, GL, DX ... and also correct render2texture.

I think we will not fix it for the legacy backends as this means a complete overhaul on how textures (your images, your font glyphs ...) are handled internally on these backends. I assume we will sooner or later switch to sdl.rendermax2d as default one and ditch brl.glmax2d, brl.d3d9max2d, ... and the whole "brl.system" path in favor of the equivalents in SDL. Platforms/Targets like Android, Raspi, ... already have to use it anyways. So best thing is to unify this for all platforms. This will also ease the pain regarding window handling (resizeable Windows, extra configs, ...) and also things like multi-max2d-windows etc.

Projects done:
I can only talk about my game - which is played by some thousand players around the world (subject wise more German-speaking countries as the economic-sim-games thing was popular in the 90s here). I do not earn money with it (I do not want it - people should just enjoy the game). But I also do not promote it (no steam, no youtube stuff). So judge on your own if this is "popular" enough.


bye
Ron

imaginaryhuman

@Derron ok thanks for the info.

if I use the sdl.rendermax2d ... then this implies I would use normal blitz drawing commands to draw things, such as DrawRect etc. But how then would this allow for e.g. the construction of meshes, or use of shaders, etc? How does one use this sdl backend and also have access to these more modern features beyond render textures? Like if I need to build a piece of geometry which uses multiple texture coord channels and multiple textures and some of those textures might be render textures, maybe with a normal map etc.... how is that done?

Also do the render textures support multiple formats beyond just RGBA32, like float-based or 16-bits per channel etc?

Derron

I cannot answer these questions - as I am only using the 2D stuff with RGBA (or ARGB) 32 bit textures.

I think for now SDL2 cannot do 3D "directly":
https://discourse.libsdl.org/t/future-3d-api/33485/9

As with the current Max2D (see "2D" !) you will also not have convenient 3D-Access.
To work with multiple backends you need some abstraction so your meshes would be created regardless of OGL or D3D backend. Dunno if MiniB3D or OpenB3D can work together with "SDLRenderMax" or the SDL-backend. Maybe @markcwm can answer this.


bye
Ron