Blitz3D "NG"

Community Forums/Developer Stations/Blitz3D "NG"

kfprimm(Posted 2016) [#1]
Hey guys,

I want to introduce my new project that is (tentatively) titled "Blitz3D NG." It is an attempt to modernize Blitz3D and restore it to relevance by polishing off many of it's rough edges and overhauling a few things "under the hood."

You can check out the changelog on GitHub. Download a prebuilt copy (v200-alpha.002) to play with and check out the source!

(DISCLAIMER: This is a prerelease that has only been tested on my Windows 10 system. The VC standard library is statically linked, so it should run without issue. If it complains about needing something else try installing this.)

Here's a quick summary of the changes:

- Everything is compiled with Visual Studio 2015 & the latest Windows SDKs.
- DirectPlay has been disabled (commented out), so on Windows 10, the app no longer requires DirectPlay to be installed.
- The IDE & runtime are now "DPI aware." This means apps will run at their native resolution, instead of being scaled. (Again, mostly relevant on Windows 10. Note: does not work yet with exported *.exes.)
- Added commands to get DPI scale, relative to 96dpi.
- Misc. joystick commands have been added.
- Added the "BB" icon to the IDE executable & windows. It's the little things, right? :)

For now, can check out my very rough roadmap. I will be adding to it as particulars are revealed through my own hacking (as is the case of the DPI commands) or suggestions are made by the community (in the case of DirectPlay "removal"). To give you a general explanation, I'll explain my mindset a little.

I have played around with the B3D source since it's release two/three years ago. Over the course of a half-dozen failed attempts to compile it with GCC/clang and make the code cross-platform, I've become acquainted with the source & now realize that a conservative, realistic "test, release" cycle is the best way to precede. (Rome wasn't built in a day!) The stability and resilience of Blitz3D after all these years is what makes it great. I want to preserve that.

Stay tuned for particulars about 64-bit compilation, new OpenGL/Direct3D renderers, and all the other flashy things. It's a long road ahead, but it is motivating because I remember having a lot of fun with BB back in the day. Being able to sit down, fire up a simple code editor, and churn out a playable game in a matter of hours as a kid was great. I want to recreate that experience for myself & offer the same to others.

I'd love to pick up some alpha users. Let me know what you're interested in seeing, play with it, and join me on GitHub. Open a ticket for any bugs or suggestions you come across. (Code contributions are welcome as well!) Shoot me an email at kfprimm@... if you'd like to chat.



xlsior(Posted 2016) [#2]
Good luck!

MikeHart(Posted 2016) [#3]
Thanks Kevin,

over the weekend I will have a go. I run Win7 Home.

MikeHart(Posted 2016) [#4]
Ok i could not resist. I downloaded the prebuild version. Placed it on my desktop. Path without spaces.

Both versions report "toolbar bitmap failed to load!" error and stopped.

RemiD(Posted 2016) [#5]
@kfprimm>>good luck !

RustyKristi(Posted 2016) [#6]
awesome update kevin!

Naughty Alien(Posted 2016) [#7]
..good luck..if you succeed, you will be for sure, some sort of superhero.. :) .. i hope you will succeed..

grable(Posted 2016) [#8]
Since im on win10 il try this out.
And for those getting the missing toolbar image, it looks for "%BLITZPATH%\cfg\ide_toolbar@...". I just copied the one marked @2.

EDIT: 64 bit version is a bit unstable, it crashed while clicking around in the docs (Basic Tutorials->Example Code->???)
And doesnt appear to load files without crashing yet..

RemiD(Posted 2016) [#9]
Since you will probably have to rewrite the procedures/functions/systems, i suggest to split the senseless "updateworld()" in two separate functions :
updateanimations() (or upatejointsandskinnedvertices())
updatecollisions() (or detectcollisionsrepositionellipsoids())

I also have suggestions concerning the final appearance (how it should look like) of the combination of different textureblend, surfaceblend, cubemapblend, which seems to be incorrect with the original Blitz3d...

If you are interested i can provide some code examples (for Blitz3d)

kfprimm(Posted 2016) [#10]
Mike, I've replied to you on GH, but the download link has been updated with a new build that should fix that problem.

Thanks for playing with it grable. Yeah, I haven't spent much time with the 64-bit IDE & actually meant to exclude it from the build. It's been removed from the latest ZIP.

Thanks for the well wishes, everybody!

RemiD, yeah code examples would be great! Feel free to open an for each of your thoughts on GitHub and I will tag them accordingly.

RemiD(Posted 2016) [#11]
@kfprimm>>concerning the blend modes and blend formulas (of textureblend, of surfaceblend (using brushblend), of entityblend), they are explained here :

but it would be good to know if these blend modes and blend formulas are a specificity of Blitz3d or of Directx7, because maybe it is possible to create others blend formulas (and thus others blend modes), it would be great ! (for example for the moment we have "alpha", "multiply", "add", but we could have "substract" or others blend modes (using others blend formulas) which you can see in an image editor with layers)

kfprimm(Posted 2016) [#12]
They are B3D constructs (see here). If you look at the D3D docs, there are a bunch of other options.

If you write up specific cases of what you're looking for, I'll gladly take a whack at figuring out how to get them in there.

RemiD(Posted 2016) [#13]
Ok, i see a subtract blend in the d3d docs, however can you create other custom blend modes or is it restricted to the D3D ones ?

GW(Posted 2016) [#14]
Good luck!

Personally, I think holding on to the b3d language is a con rather than a pro, but the 3d api/commandset is still one of the better api's out there.

kfprimm(Posted 2016) [#15]
I'm with you. The language certainly isn't the ideal one if you're a seasoned vet, but for a beginner/casual coder it's great. That said, there are a few things I'd like to expand with the language, that shouldn't cause any backwords compatibility issues. A Strict mode would be nice and a some default constants, like KEY_*, GRAPHICS_*, FX_*, etc.

kfprimm(Posted 2016) [#16]
RemiD, as far as I know, just the ones on that list.

Steve Elliott(Posted 2016) [#17]

...use upatejointsandskinnedvertices())...detectcollisionsrepositionellipsoids())

What a hideously long winded language that would make lol.

RustyKristi(Posted 2016) [#18]
I agree with Steve here, flags will just do fine or something else.

Kryzon(Posted 2016) [#19]
A suggestion is to drop the .B3D format and support something more universal, like OBJ, DAE or FBX.
You can probably use something like Assimp to avoid having to read any specifications, but I don't know in what state that library is in.

RustyKristi(Posted 2016) [#20]
B3D is a nice format to have to drop it but maybe adding more format support. Moving on and leaving legacy code is a good thing but B3D format is what makes Blitz3D.

The format itself is very much associated with Blitz3D, collada is open format but it is still a mess.

kfprimm(Posted 2016) [#21]
The funny thing is Assimp can load B3D!

Yeah, I was planning on using Assimp, or finding an alternative, because the .X loader uses IDirectXFile which, even in it's latest iteration, is a Windows-only, non-FOSS deal.

That would be a great contribution, if anyone is feeling up to it. The loader code doesn't look all that scary.

RustyKristi(Posted 2016) [#22]
ha yes that is right. You can't get rid of B3D format, it's become one of the standard, not being widely used today but still relevant. :-)

RustyKristi(Posted 2016) [#23]
Difference made some progress but with Blitzmax, maybe something useful to look into..

Blitzplotter(Posted 2016) [#24]
You're list of to do's makes for some interesting reading, the one regarding the need for directplay is of particular interest to me.

This almost has me sold on upgrading to a Windows 10 PC, whilst I'm happy with my W7 box - trialling a B3D project I've been working on for a while within a version of B3D that does not require directplay is interesting.

Good luck ;)

RustyKristi(Posted 2016) [#25]
It would also be nice to get Ploppy's work in the mix if someone can get hold of the current situation with the source code turnover stuff. So as it may sound chessy but at least his years of work will not go into waste and his Blitz legacy will live on. :)

MikeHart(Posted 2016) [#26]
I was looking at some YT videos from 8-9 years back. Damn some people achieved great looking stuff with Blitz3d. It has one of the best APIs out there. The language is good enough to get things done.

Kevin, are the steps described on Github to get everything compiled under Win7? If yes, i could try to help out regarding assimp

kfprimm(Posted 2016) [#27]
In theory, yes. In practice, I guess you'll find out. :)

Everything is bundled in the repo now, so if you install premake and VS2015, it should *just work.*

Let me know if you run into strange blocks. I'm sure we can improve the build instructions.

Any progress you can make would be appreciated. If you're unfamiliar with premake, don't worry about it for now. You can drop the .lib file in common/x86 and the headers in common/include. If you manage to make some headway, I don't mind handling the final packaging.

RemiD(Posted 2016) [#28]

What a hideously long winded language that would make

yes it is better to have a nonsensical function (updateworld()) and to write it just before renderworld() with no idea what is going on (like most coders here apparently do)

A suggestion is to drop the .B3D format and support something more universal, like OBJ, DAE or FBX.

and for those who use a modeling/rigging/skinning/animation tool like Fragmotion you just forget about them ?
Please keep the b3d format.

@kfprimm>>you may want to add the addons by Bobysait (possibility to get the skinned vertices positions, and possibility to create bones (joints) in code, and possibility to set the influences (weights) of some bones (joints) over some vertices.
They are here :

Steve Elliott(Posted 2016) [#29]
RustyKristi gave a much better solution...but you're still pursuing your ridiculous idea of how a computer language should look.

I agree with Steve here, flags will just do fine or something else.

...use upatejointsandskinnedvertices())...detectcollisionsrepositionellipsoids())

Oh please! It's called coding not writing a novel!

MikeHart(Posted 2016) [#30]
Blitz3D NG shouldn't drop the B3D format. I am sure, with the usage of a library like assimp, we can have other formats as well and keep the supported ones.

@Remi: I find you renaming suggestion going overboard too. The help file should explain what it does. Then you know as a coder. As a newcomer to a tool, I tend to study the docs at first to see what is available and possible.

But hey, open an issue to add your request in github. This way, it doesn't get lost here. If enough people want this, Kevin might be convinced that it is a good idea.

In generell, I would not change fundamental functionality like this one. Rather enhance it. Introduce a flag, if you don't want it to do certain steps. Stuff like that.

@Kevin: How do you want to deal with suggestions/needs of the people?

Derron(Posted 2016) [#31]
Dunno if this possible with Blitz3D - but can't you just hook into the function call?

update() internally calls updateStuffA() updateStuffB() ...
but then update() would call _customFunctioncallback() if defined so (and skip the updateStuffA() etc.).
this callback then could reorder stuff, or skip stuff ...

With oop of course you would just override the worldcontroller to have your own run of "update()".

@ Blitz3D NG
Make it cross platform, make it renderer agnostic (or allow ogl, ogl es, dx9/dx11, ...).
Until it does that, I do not see a bright future except for existing users (newer ones might not need "cross platform" yet, but they _look_for_it - to secure future progress of their "big hit" games).


RemiD(Posted 2016) [#32]
I suggested UpdateAnimations() and UpdateCollisions() but you chose to disregard that... (probably because of the troll within you (which we all have don't worry :P)
The 2 others names were more here to describe what is going on.

Personnaly i don't use Blitz3d collisions system, it is buggy and only usable for primitive gameplay. (i use linepicks and pickables)

RemiD(Posted 2016) [#33]

In generell, I would not change fundamental functionality like this one.

@MikeHart>>please explain to me how it is better to be forced to update joints/skinnedvertices and to turnmoveellipsoids/detectcollisions/repositionellipsoids, at the same time. I just want to understand your logic people ?!

There is nothing fundamental about updateworld() (what world ? the world of joints and skinned vertices ? or the world of ellipsoids and collidables ?), it is nonsensical and annoying to mix unrelated systems...

RemiD(Posted 2016) [#34]
Another improvement would be to remove the vertices/triangles limit per surface, because apparently it is arbitrary and useless nowadays (apparently it was useful only to prevent incompatibilities with old graphics cards...)

MikeHart(Posted 2016) [#35]
With my own stuff, I try to maintain backwards compatibility. So you don't break old code. For your stuff, I would create new functions, but not break the existing one. Or create a switch/flag, that lets you choose what it does. As I understood it, the current function does things you don't need.

RemiD(Posted 2016) [#36]
@MikeHart>>i understand that you don't want to have to rewrite all your codes, but really, having to write :
instead of :

is not the end of the world !

Derron(Posted 2016) [#37]
See my post above: allow customization with function hooks.

If not possible, add a bitmask for enabled update stuff, and a order-array to order the update stuff.

But for me this sounds more hackish than just having a custom callback being able to run whatever the developer wants.

Of course the same should be done for "RenderWorld()" - eg. renderpasses or whatever is done there.


RemiD(Posted 2016) [#38]

you're still pursuing your ridiculous idea of how a computer language should look.

i have not seen that, so i will answer calmly so that you can (maybe) understand the advantage of having a function name which is descriptive of what is going on in the function :
following your logic, we could have a function named like that :
where the name of the function is not important, since we can rely on the documentation to understand what is going on in the function and activate/disactivate parts of the procedures with flags. (in this case the ellipsoids will be turned moved, the collisions detected, the ellipsoids repositioned, but the animations, joints, skinned vertices will not be updated.)

Ok why not.

MikeHart(Posted 2016) [#39]
Another improvement would be to remove the vertices/triangles limit per surface


Did you add this as an "issue" to the github?

EDIT: Nevermind, will do it for you.

MikeHart(Posted 2016) [#40]
@kfprimm: Regarding the FMOD replacement. Besides OpenAL, do you have another idea what could replace it?

Steve Elliott(Posted 2016) [#41]
If we learn a foreign language or a computer one - we DO have to put some effort in to learn (good documentation does help). And once learnt it because second nature.

I don't see any C++ Developers complaining over functions like 'cout' - console output. It's very quick to type, but if you add a few functions like upatejointsandskinnedvertices())...detectcollisionsrepositionellipsoids()) very quickly you can't 'see the wood for the trees'. Programs become very verbose and harder to understand - not-to-mention longer to type.

Anyway I guess we'll agree to disagree on this one :)

RemiD(Posted 2016) [#42]

but if you add a few functions like upatejointsandskinnedvertices())...detectcollisionsrepositionellipsoids()

@Steve>>i never said that we must have long functions names, i first proposed updatecollisions() and updateanimations() instead of updateworld() (which you have still not considered yet, not sure why...)

Consider that sometimes it is useful to update the animation, joints, skinned vertices, of a rigged skinned mesh, several times during the same loop (if you want to animate different parts of the body independently or to update the caster of stencil shadows...)
So you see the problem with updateworld() ? This would update all animations, all joints, all skinned vertices, all ellipsoids, calculate collisions, reposition ellipsoids, several times. Not the best approach...

Anyway, these are just suggestions, do as you want.

kfprimm(Posted 2016) [#43]
RE: B3D format. Don't worry, it's not going anywhere. However Kryzon's point is well taken & we should definitively improve the loader capability. As previously discussed, Assimp looks like a good choice.

RE: UpdateWorld/UpdateCollision/UpdateAnimations. I think there's a legit discussion to be had about finer controls. First off, can someone who'd like to see this (Remi?) provide a concise code example demonstrating the need? Think "documentation-grade" code example. It should be more complex than a simple find & replace of "UpdateWorld()" with "UpdateCollisions()\nUpdateAnimations()." If 80% of the benefit would be semantics, as Steve points out, that's not really justifiable or needed.

@Remi, thanks for the link! I was looking for that because I remember thinking he had added some sensible "getters." The vertex limit is not arbitrary, unfortunately, but rather a D3D7 limit. See the GH issue Mike opened for more details.

@Mike, as far as I'm concerned, anyone who really wants something added will take the initiative to open a GitHub issue so there can be some good natured discussion around it. Regarding FMOD alternatives, maybe PortAudio]? It's MIT licensed. We'll have to pull some other code in to read the various sound formats. OpenAL would still require us to dynamically link. I'd really like to get B3D back to being self-contained.

@Ron, yeah D3D9+, OpenGL, macOS, linux, etc. is the ultimate goal! Good point about finer/efficient render pass control.

TomToad(Posted 2016) [#44]
Re: UpdateWorld()

Why can't we have both options? An UpdateWorld() for backward compatibility and an UpdateAnimations()/UpdateCollisions() for finer control. Just use whichever works best for the situation. I don't see why we can't add new functionality without needing to completely replace old.

RemiD(Posted 2016) [#45]
Splitting updateworld() in 2 separate functions (for example updateanimations() and updatecollisions()) would allow to use/update only one system depending on what you need in your game and only when needed. (i only use updateworld() to animate my rigged skinned meshes...)
Why use/update a whole system if you don't need it ? I don't see any advantage...

Steve Elliott(Posted 2016) [#46]
I'd say backward compatibility is key, but yes, you could add improvements.

I would abbreviate those lengthy examples, such as updateanimations() to update_anim() or similar though.

kfprimm(Posted 2016) [#47]
Well, if your concern is performance, it's (in most cases), a moot point. If an entity doesn't have a "type", no collision code is executed.

That being said, we could add a check here to see if there are any collisions configured (i.e. Collisions) & avoid the additional iteration if it's not needed.

Somebody write up a stress test that demonstrates a bunch of meshes being animated. Then, I'll post a build with the collision system disabled and then we can go from there.

RemiD(Posted 2016) [#48]

I was preparing a stress test for you and, as you may know, there are 2 ways to update the animation of a rigged skinned mesh :
->you can use animate(), then use updateworld()
->you can keep track of the current frame (pose), then use setanimtime(), then use updateworld()

and i was surprised how animate() + updateworld() takes almost twice more time than setanimtime() + updateworld() !

Here is the stress test (400 rigged skinned meshes animating)

The animation appearance seems to be the same when using setanimtime() and when using animate()... And another advantage is that when you use setanimtime() you can specify a different "start frame" (start pose) for each character so that they don't animate the same way. (not synchronously)

Rick Nasher(Posted 2016) [#49]
Actually, in RemiD's defense:
Other languages also have split update functions too.
Unity for instance has Update() and FixedUpdate(), so it might actually have some advantages to do so, as he tried to explain.

Bobysait(Posted 2016) [#50]
On UpdateWorld call, the animations use transition, which SetAnimTime can't do.
So it's slower, but it is more accurate if transitions are required.
Then, UpdateWorld create a list with all entities (hidden or not, in view or not) then apply the animations on all entities. When you use SetAnimTime, there is much to think you don't don't update everything but only what you need.

Anyway, regarding "UpdateWorld", I don't see any real good reason to not keep it and think about using two functions instead of one ...
Actually, there is just to add the other independant functions (UpdateAnimation / UpdateCollisions) so that UpdateWorld would just be a shortcut that calls the 2 functions one after the other.

So, I think you're maybe spending too much time on something that does not need much more consideration.
Am I wrong ?

ps :

[...] upatejointsandskinnedvertices()
[...] detectcollisionsrepositionellipsoids()

You can't be serious on this one, are you ? :D
At least you made me smile :)

RemiD(Posted 2016) [#51]
Descriptive functions names are funny ? Not sure who is strange here. (i have functions with longer names)

Anyway, regarding "UpdateWorld", I don't see any real good reason to not keep it and think about using two functions instead of one

ok why not mix the linepick system in updateworld(), eyh why not ? i mean since you all seem to think that it is ok to mix unrelated systems, let's mix !
in the end we could have one big function which would update all unrelated systems and call it UpdateBlitz()
(just joking)

Actually, there is just to add the other independant functions (UpdateAnimation / UpdateCollisions) so that UpdateWorld would just be a shortcut that calls the 2 functions one after the other.

yes that's a good idea, it would satisfy everybody

BlitzSupport(Posted 2016) [#52]

yes that's a good idea, it would satisfy everybody

Famous last words!

Good luck with the project, though.

MikeHart(Posted 2016) [#53]
Kevin, why is the topic title changed?

kfprimm(Posted 2016) [#54]
Thres a bug in the edit form where it strips it out. Fixed!

MikeHart(Posted 2016) [#55]
Cool. :-) I the repro to compile so I can try to help out.

gpete(Posted 2016) [#56]
loaded the prebuild.... works fine with my own B3d programs....This is very exciting- I need to add the complete paths to your demos graphics and models- My Win 10 seems to require it..
thanks and continue forward! ;)

kfprimm(Posted 2016) [#57]
Hey, thanks for giving it a shot. Can you elaborate a little on what requires full paths? It's possible there's a compatibility bug that could be dealt with easily. Thanks!

Quick update for everyone: I've been steadily working on moving the more abstract code away from the OS/env specific implementation (DX7, Windows, etc). At the same time, I've been experimenting with LLVM to replace the x86 IR/asm generation currently in place.

On that front, I've got the compiler running on my iMac and able to compile basic programs such as,

Function FullName$( fname$,lname$ )
  Return fname+" "+lname
End Function

Print "Hello, " + FullName( "Kevin","Primm")

In my testbed, "Print" just forwards the string to "printf," which goes to the terminal. No graphics yet!

Of course, it's far from perfect & frankly quite frail, but it's a start. The great thing is that the parser is untouched, so all existing BB programs are parsed exactly as the original compiler does. The output code is only thing that has changed.

MikeHart(Posted 2016) [#58]
Wow. That is awesome. Next week i want to study the source more to aee how assimp could be utilized. Had not time for this and hope I find it next week. But don't get your hopes up. I am on war path with anything C/C++ related since the 90s.

skidracer(Posted 2016) [#59]
Is anyone using Kevin's version? I am still to build my new windows box but it's on the list.

Moved from General Discussion.

virtlands(Posted 2017) [#60]
Hi kfprimm, This is great, I ran the prebuilt copy of Blitz3D "NG" and it runs just fine.
When I tried to compile the source code I received lots & lots of errors ::

kfprimm(Posted 2017) [#61]
Hey, sorry about that. I've fixed it now.

Check out the commits page. The commits that will build properly have a green check mark after the commit timestamp. The red Xs will not.

To select a particular commit, use "git checkout <hash>" where "<hash>" is one of the commit IDs on the right.

To give everyone a quick update: I'm still toying around with LLVM but will be returning to work on the code restructure so that we can inch closer to a GL renderer.

3DRCzy(Posted 2017) [#62]
Will you fix the compatibility with Fast Libraries? It builds fine, but none of the images show up at for FastImage. Also, once i include Fast Extension and set it up, i get a "SetBuffer" Error. Great job on this btw, liking it so far.

kfprimm(Posted 2017) [#63]

I don't have any experience with any of the FastLibs and know only a little about them. Was it v1.108 that broke them? The problem is the the git history only shows a few tweaks before the open source release. None of them look like they effect data structures FastLibs depends on.

Any chance we can get the source to the libraries themself? Better yet, what functionality are you specifically looking for? It may be easy enough (and cleaner/more efficient) to just directly implement it into the project.


Rick Nasher(Posted 2017) [#64]
Features I'd like to see:

1. B3D should be kept. It's too established and has nice features. Perhaps can even be extended if desired?
FBX is I guess the next best thing feature wise, but a bit less clear as is avail in a bit and text type format.

2. To replace DirectPlay

I would like to see a Blitzefied wrapper included for the Photon Networking Engine:
It's apparently used by all the great AAA studios and has all the cross platform multiplayer networking goodies in there.

The world's #1 independent networking engine and
multiplayer platform Fast, reliable, scalable.
Made for anyone: indies, professional studios and AAA productions.

We Make Multiplayer Simple.
[Get Photon FREE]

Or, use the Unity Networking extension DLL, which as I believe is based on RAKNET, but may need more fixing for is under development and not completely bug free. From the README here: ):

The Unity Networking extension DLL is the open source component of the Unity Multiplayer Networking system. In this DLL we have the whole networking system except the NetworkTransport related APIs and classes. This is all the high level classes and components which make up the user friendly system of creating multiplayer games. This document details how you can compile your own version of the Networking extension DLL and use that in your games and applications.

What license is the Networking extension DLL shipped under?
The Networking extension DLL is released under an MIT/X11 license; see the LICENSE file.
This means that you pretty much can customize and embed it in any software under any license without any other constraints than preserving the copyright and license information while adding your own copyright and license information.
You can keep the source to yourself or share your customized version under the same MIT license or a compatible license.

3. Further more I would love to see a basic physics engine (also Blitzefied).

4. GUI commands from BlitzPlus build in, but this is probably too Windows only, so would need to be reworked.

This would all be really nice features to have in a NextGen Blitz3D. One doesn't need to make use of these, but I think would really be nice to have build in from start.

Blitzplotter(Posted 2017) [#65]
To give everyone a quick update: I'm still toying around with LLVM but will be returning to work on the code restructure so that we can inch closer to a GL renderer.

Haven't had a chance to check your project out just yet, exciting stuff though ;) I intend to have a play this weekend.

I use fastlibs also with the version of Blitz3D I've currently got but haven't updated my Blitz3D for fear of 'breaking' my current fastlibs associations.

I wouldn't be too worried about the fastlibs - I think it might've been someone called Mikhail V who used to post about his fastlibs, but he's been absent from the forums for a while.

3. Further more I would love to see a basic physics engine (also Blitzefied).

Whilst this'd be nice, JV-ODE is a great add on lib at a very reasonable price - loads of examples and I've had some great fun with that over the years.

I don't know how hard it would be to implement Rick's suggestions, but they sound interesting ;)

virtlands(Posted 2017) [#66]
Hi again,... I tried to compile it yet again, and I can't get past step 1. I get the following error :
Error: C:/code/blitz3d-ng/blitz3d-ng/premake5.lua:107: module './src/runtime/premake/init' not found:

kfprimm(Posted 2017) [#67]
Sorry, in the middle of some significant changes related to module structure and documentation generation. I'm getting very close to having the core runtime running on macos/linux.

To fix your issue, run "git checkout 65a9e9c1af7edd1af48aefb88a3d20e9c0922f3d" to switch over to a known stable build. I really should tag one every once in a while.

You can find stable commits here: They have a green check mark next to them.

kfprimm(Posted 2017) [#68]
Also virtlands,

Are you interested in messing with the source, or do you just want an up-to-date build? If it's the latter, I can focus the next couple of sessions I put in on setting up the CI tool to push the binaries to a web server automatically.

Then, you can just download a ZIP file from GH with everything ready to rock & roll.

virtlands(Posted 2017) [#69]
Hi kfprimm, thanks for the new links. I have more success this time. This is a thrill.
I used your green-checked commit from April 9, -->

Yes, it would be great to mess with the kfprimm source, (plus, we should also get your up-to-date builds).

I was fascinated by Ploppy's attempt to create 64-bit integers & 64-bit double floats, using "%%" and "##" , and using "$$" for unicode.
Ploppy's HardWired page (Part XIV) ::

Is blitz3d-ng 64-bit or 32-bit?

Rick Nasher(Posted 2017) [#70]
If it's a x64-er then does that mean you reworked the assembler bit in Blitz3d? I believe Ploppy was struggling with that for a while.

kfprimm(Posted 2017) [#71]
Yep, virtlands, I know exactly how you feel. It's awesome to watch it build the whole project.

The freeimage source was moved to the "src/" folder between the latest commit & the old you're working on. So just move "./src/freeimage341" to "./freeimage341" and everything should be good.

Re: x64.

It's not anywhere close to being 64 bit. Only the launch utility (Blitz3D.exe) & IDE compile & link to x64. A good chunk of the modules are now compiling to x64 (Mac+Linux too!), but I have yet to even touch the compiler.

Frankly, it's going to be too much work to try to retro in 64-bit instructions. I played with LLVM, but didn't make a lot of progress due to my lack of familiarity. I think I'll take the monkey/BlitzMax-NG route and repurpose the compiler to spit out C++ code instead. Portability for cheap.

I actually got some basic programs compiling last month. I modified the compiler to dump the AST (abstract syntax tree) to JSON & then wrote a ruby script that would parse the JSON & spit out C++ code.

I ended up throwing away all the code since I did it on one of my Macs and, without a runtime to link against, the generated code couldn't run. Never mind the fact that the runtime system uses an in-house linker/assembler. (Side note: Mark Sibly is an exceptionally clever man.)

So, I'm now pounding away on restructuring the runtime so that all the OS-specific components are separate. That allow for the addition of a GL driver, which will make mac/linux porting easier. Though, prior to that I may implement "Print" & "Input" as terminal functions so I can mock some basic programs in C++. I've got an idea to implement a console/gui mode like BlitzMax with some type of "ConsoleDriver" that will let you choose between the "legacy" Graphics Print/Input/Locate functions & stdio outputs.

virtlands(Posted 2017) [#72]
Frankly, it's going to be too much work to try to retro in 64-bit instructions. I played with LLVM,...

That's fine, we can still use 64-bit data-types and larger on a 32-bit instruction set.

C Data types & limits :
The great news is that I just now compiled your source-ng with very nice success for Visual Studio 2015 Community Edition ....

.... using green-checked commit from April 9, -->

Visual Studio 2015 Community Edition results
========== Build: 41 succeeded, 0 failed, 0 up-to-date, 1 skipped ==========

Visual Studio 2017 Community Edition results
========== Build: 35 succeeded, 4 failed, 0 up-to-date, 1 skipped ==========

I used two separate dev command prompts, one for Vis Studio 2015, and one for Vis Studio 2017, (I have both IDEs installed).

For some reason, your code likes Vis Studio 2015 better, which resulted in zero errors & 230 warnings when compiled ( in Vis2015 ) .
There were 4 fatalities in Vis Studio 2017.

I also tested the resultant Blitz3D.exe (with sample BB programs), and it apparently works perfectly.
This shows my recent premake5 warnings (in Vis2015) -->

kfprimm(Posted 2017) [#73]
Re: Visual Studio

Great to hear that! Yeah, I haven't installed VS2017 yet. I'll do that next time I'm booted into Windows & add it to the CI build matrix.

Re: 64-bits

Yeah, I meant instructions as well as data types. According to my limited understanding of machine instructions, you have to modify the generated assembly to handle long/doubles differently from int/floats.

However, let's assume that hurdle is overcome (it eventually will via a C++ translation layer, I want mac/linux support!): there is a fundamental problem with the language itself. Pointers pose a real problem. Right now, pointers (such meshes, textures, etc) are converted and stored as integers.

On a 32-bit system, pointers are 4 bytes. On 64-bit systems, they are 8 bytes. (Hence the "bit-ness", right?)

That means that the only way to have 64-bit Blitz3D & maintain compatibility with existing code is to make all integers longs, and all floats doubles. That's not the end of the world, but that does mean you're using more memory than you might need.

...then again. Blitz3D didn't support bytes in an era when memory was much more valuable & we're all still here.

Anybody have thoughts on this? I have a few alternatives in mind, but they require modifying the language.

col(Posted 2017) [#74]
Right now, pointers (such meshes, textures, etc) are converted and stored as integers.

One idea to get around this issue is that the programmer doesn't have a pointer that is an integer but you give them a handle that is a standard 32bit integer. User side; the code stays the same. Internally you can deal with it however you want to - map the handle to the real 32 or 64 bit pointer for eg.

Just a thought.

virtlands(Posted 2017) [#75]
...I read all that. Perhaps you can compile 2 versions of Blitz3D for us. It's just an idea.

(a) 32-bit version of Blitz3D (simpler code)
(b) 64-bit version of Blitz3D (more complex code)

kfprimm(Posted 2017) [#76]
Interesting idea Dave. It could be #ifdef'ed out on the 32 bit build.

virtlands, that's not a bad point. Maybe the expectation going into a 64-bit is that things won't work out-of-the-box. Maybe a pointer type should be introduced along with the other data types.

The addition of a "strict" mode like BlitzMax would catch any errors.

You know what, I bet Yasha has some thoughts on how this could be handled. This kind of stuff is right up his alley.

Vane Brain(Posted 2017) [#77]
Don't stop working on it! It's very cool!

kfprimm(Posted 2017) [#78]
Yep...especially when you can compile a basic B3D program & run it on your Mac!

640x480 windows.

Left: native, OpenGL (Retina-aware)
Right: wine, DirectDraw

This is still very rough, but it does work!

You can check out the generated source.

I also have some basic OpenGL 1.1 code in place that can render meshes without many options but I'm not going to post any screenshots of that until textures are working & whatnot.

I'm thinking I may do a screenshare video that walks through the source & structure of the project.

By the way, the latest code is on GitHub. So, if you have a Mac (and some patience) you can build the above example yourself.

BlitzSupport(Posted 2017) [#79]
Awesome work!

virtlands(Posted 2017) [#80]
...especially when you can compile a basic B3D program & run it on your Mac!

Thanks kfprimm for the GLFW topic, I didn't know about it till I found it in your DrawImage.c code.
{ GLFW = Open Source, multi-platform library for OpenGL, OpenGL ES }

GLFW on GitHUB -->
GLFW (precompiled binaries) -->

DrawImage.BB on GitHubGist --

For those that are curious, you can compile that GLFW source code into a DLL :: { GLFW on GitHUB --> }

As an example, you can start by using the CMAKE GUI --
Create a subdir named "build" within your GLFW dir ...

Within CMAKE, click on Configure .

As seen in the above screenshot, next click on "BUILD_SHARED_LIBS"
Then click on Generate .
It shall create a solution file ( *.SLN ) file for you inside the build subdirectory .

If for some reason you don't want to try CMAKE, then you can get try out the solution project from me -->

Next, click on that GLFW.sln file to start your Visual Studio.
( I recommend using Visual Studio 2015 Community Edition. )

Inside Visual Studio click on Build .
Therefore, if all is successful, you'll find a brand new glfw3.DLL inside your Release or Debug subdirs ::

This next screenshot demonstrates some success after copying the DLL into the Examples\Release directory:

OR, if you wish, you can ignore all that complex stuff and just download the binaries directory from the GLFW website --

kfprimm(Posted 2017) [#81]
Nope. It's all open source. No secrets.

You need to add the "src/runtime" directory to your include paths.

That being said, the Windows stub isn't setup with a "WinMain" so it won't compile out of the box. If you want, you can try adapting the Mac stub (should compile without too much fuss.)

The other link options can be found here:

kfprimm(Posted 2017) [#82]
Also, I've setup a Discord chat. If anyone needs help or wants to talk about the project, feel free to swing by.

Rick Nasher(Posted 2017) [#83]
Haha! The good Amiga Boing Ball. :)

virtlands(Posted 2017) [#84]

virtlands(Posted 2017) [#85]
Hi again K.Primm, I'm somewhat confused about post (#81)

You need to add the "src/runtime" directory to the include paths of which project?
Also, I still can't find commands.h ..

kfprimm(Posted 2017) [#86]
There are several commands.h. Each module has its own. Look at the full include directive in the example C file. You'll notice it corresponds to a file under that directory.

virtlands(Posted 2017) [#87]

virtlands(Posted 2017) [#88]