I've asked almost the same question for BlitzMax (http://www.syntaxbomb.com/index.php/topic,3442.0.html), so I'd like to know what you liked most about BB3D and where would you see room for improvement, both language wise and features?
Personally I hated the way types where accessed with type\x, where I would had preferred type.x
I'm asking because Mike and I started something like BB3D (but cross platform), so... Do you actually still see the need of kind of an easy accessable language (non oop)?
Thanks!
Personally I always felt the Blitz BASIC syntax old-fashioned so never really used it. Yet to turn out something like C++/Java would be over-kill for such a product. It's a tricky fine line to tread.
The 3D side of things was very simple and effective.
I personally think the OpenB3D guys (markcwm and angros47) already got this covered if they can pull the emscripten and android target.
But then again this does sound interesting Martin.. what do you have in mind? ThinBasic or from scratch? ;D
If we're talking about pure BB3D stuff then there's also kfprimm's Blitz3D NG project which is now a few months inactive.
Although I am a 2D guy but was one the first who bought Blitz3D, I liked the idea it has a printed (wired!) manual.
I liked the easy to remember and consistent keywords, the good performance back then when compared to say Dark Basic!
How ironic that Dark Basic guys are doing great right now, 'Someone' should have been in their place and even better.
I hated the \ to access type fields too and hate the fact that it is based on DX7 for more than a decade now!
Quote from: sphinx on September 16, 2017, 10:37:11
Although I am a 2D guy but was one the first who bought Blitz3D, I liked the idea it has a printed (wired!) manual.
I liked the easy to remember and consistent keywords, the good performance back then when compared to say Dark Basic!
How ironic that Dark Basic guys are doing great right now, 'Someone' should have been in their place and even better.
I hated the \ to access type fields too and hate the fact that it is based on DX7 for more than a decade now!
I have used both and with Blitz3D, you can overcome your DX7 dilemma by using wrappers. ;) I find the irrlicht one of the best so far. With DarkBasic and AGK, the problem is the language when it gets bigger, graphic performance is way better of course with DX9 or OpenGL (agk).
Quote from: RonTek on September 16, 2017, 10:08:21
I personally think the OpenB3D guys (markcwm and angros47) already got this covered if they can pull the emscripten and android target.
But then again this does sound interesting Martin.. what do you have in mind? ThinBasic or from scratch? ;D
If we're talking about pure BB3D stuff then there's also kfprimm's Blitz3D NG project which is now a few months inactive.
It is something from scratch. The goal is to create a game development tool/language, where you don't have to deal with the underlying technology. In the same spirit of AGK/Blitz3D. No need to install this sdk, that sdk. Just code your game and press run or create a final executable to release. The focus is 3D but you will be able to use 2D technics as well.
With the success of AGK, we believe that there is still a market for BASIC languages that are easy to code and have a powerful API.
The projects you mentioned are all great and I hope they take off.
And if you wonder about Cerberus X. It is and will still be there and has our support. That won't change. This project is totally unrelated to Monkey/Cerberus.
What is the graphics engine written in Mike?
C++. ;) By from scratch I ment we create all the tools from scratch. IDE, Parser/Compiler, etc.
Of course we utilize libraries that are available for doing things.
C++ only does logic lol :P
Quote from: Steve Elliott on September 16, 2017, 11:36:22
C++ only does logic lol :P
Ah you ment which graphics engine we will utilize? Last tests where done with Irrlicht. So it can be DX or OpenGL I think.
Quote from: MikeHart on September 16, 2017, 11:38:15
Last tests where done with Irrlicht. So it can be DX or OpenGL I think.
Good choice. It also supports software renderer (BurningsVideo) and null device which I think is for headless.
Cool ;D
Well I hated the reverse solidius for types and the use of short hand symbols for data types. And as for Irrlicht, the last time I looked there was no official iOS and Android support. But then even when such engines claim to support multiple devices the documentation is either out of date or not complete.
Edit: Ideally it's best not to tie yourself down to the one SDK as with Blitz3D did with DX7.
@RonTek: Yeah I've heard about OpenB3D but never looked at it actually. Will do so!
It will be from scratch like Mike said, it will use Irrlicht as renderer engine plus some other stuff for physics, sound and so on. I've used Irrlicht for ages now and it's in a pretty good shape. Android and iOS are working as well but the team has changed. It's used by quite some professionals as well so I think it still had a bright future. Sure, there is no (official) DX11/12 renderer yet but I'm fine with that.
@sphinx: Haha oh well a printed manual. Yeah, those were the days. I work for a company doing medical devices which goes into the hundred of thousands dollars per system and even there is often no printed manual anymore. Strange times.
@dawlane: yeah agreed. Using Irrlicht means there are tons of different render pathes.
So rendering aside: It should be an easy to use tool, in terms of language is there anything which should be in? We want to do it that way, the AGK guys did it, so a Basic language which is interpreted for debug sessions BUT compiled (here's the difference to AGK) for creating executables plus the obvious C++ API stuff.
The only real thing I disliked about Blitz3d was the stock IDE. It should almost never be used when Ideal is so superior. Other than the fact it stopped being developed by Mark (a true successor never emerged) I only have a few nitpicks.
Blitz3D is good with Fast Libraries. It is limited to 3D. Yeah, I don't like field access with "\". PureBasic is like that too.
Why I like it?
It gets you to a working prototype faster than any program that exist.
Writing a 3D simulation is very easy with it, although it doesn't have double and long data type.
Features that are still rare today:
Entity system which includes Camera too, something you cannot find today.
Very useful 3D vector-matrix command set.
Very powerful and useful and simple 3D pivot implementation.
Community was the best in the world.
Many physics engines were available for it.
Great visual enhancement libraries were available for it.
What a waste!
Well, it doesn't have scene graph, but is scene-graph necessarily a good thing for everything? Ask Horde3D guys!
Simple, it still works great on Windows 10, and it looks like it will for a while.
(https://pbs.twimg.com/media/DU_tcsPW0AAmYAg.jpg)
What i like in Blitz3d :
-commands names which are similar to how a human think (similar to the english language too)
-freedom to code with the style you want. (i don't like oo, i prefer procedural imperative)
-compatible with most computers with Windows OS, and does not require to install others libraries / redistributables / codecs etc...
-i have access to almost everything i need, even the low level stuff
-i can use global variables, global arrays, goto line, to make the others programmers cringe :-*
-the compiled executables run rather fast (even if some things can be optimized)
What i don't like in Blitz3d :
-some bugs were never fixed (linepick sometimes fails on a ROAM terrain, weird behavior of buffers depending on which commands have been used before)
-some commands don't have an appropriate name
-some commands mix things which have nothing to do together (updateworld())
-some essential features were never added by BlitzResearch (possibility to create joints, to set the influence (weight) of some joints over some vertices, to get the skinned vertices positions, to only update the joints orientations/positions and the skinned vertices positions of one rigged skinned mesh, to disable bilinear filtering of textures, and i can probably find others)
Something to add, version 1106 I use for compatibility with fastlibs, if you look at true compatibility mode they have the ability to run compatibility from xp/vista/7/8 running on windows 10. The version compiled with visual studio 2017 has the option of compatibility from Windows 8. In other words what I think is that Blitz3D will be around for a long time.
I am currently following a course about generating procedural meshes, and the "teacher" uses Unity and c# and i can tell you that the same concepts/things/procedures/commands which are simple in Blitz3d are complicated in Unity... Why ? Is this progress ? No !
I like everything also! I am working on procedural terrain generation, "prebuilt" procedural "buildings" and trees, Space Exploration related sims, and a simple Minecraft-like game.
What I don't like is the method to make animated humans, animals, etc. I wish we had at the least: generic lo-poly human models (male & female) with walk, tool/weapon holding, sit-lie down and similar quadrapod animal animation routines--- BUILT IN TO the blitz command set.
@peteswansen>>if you plan to build rigged skinned meshes (with joints ("bones") and skinned vertices) so that you can animate them, you can't using the default commands of Blitz3d but you can if you add the addons by Bobysait (to create joints ("bones") in code, to set the influences (weights) of some joints over some vertices, to get the skinned vertices positions)
here : http://mojolabs.nz/posts.php?topic=105408
I like ..
* Being able to access low level mesh information as I build alot of my own stuff in code.
* The entity system in general is excellent.
* It's lighting fast to get prototype's up and running and if you structure your code well, much larger games can be written in it.
I don't like:
* The original IDE - using IDEal is a must!
* Poor documentation - a Sibly trait it seems.
* Sound support is limited.
* DX7 and Windows only and possible future incompatibility. Seems to be fine on Win10 - long may it continue.
* I've been passed up by publishers purely based on the language the game was written in. They expect easy porting / compilation to other platforms I think. I think there is a bit of industry snobbery when it comes to B3D.
* No native shadow system.
I have AGK and need to spend some time with it but it looks like I can't build meshes in code etc.. I suppose I could build meshes in Blitz3d and write a function to export to a common format.
Quote
I have AGK and need to spend some time with it but it looks like I can't build meshes in code
@Stevie G>>really ? and what about images ? and textures ? and joints ? and animations ?
There must be a way to build meshes in code, because with the trend of customizing the characters/vehicles with different clothes/armors/weapons/accessories, you need to be able to load several premade parts and merge them in a few surfaces and one mesh...
Quote from: RemiD on February 04, 2018, 17:31:16
Quote
I have AGK and need to spend some time with it but it looks like I can't build meshes in code
@Stevie G>>really ? and what about images ? and textures ? and joints ? and animations ?
There must be a way to build meshes in code, because with the trend of customizing the characters/vehicles with different clothes/armors/weapons/accessories, you need to be able to load several premade parts and merge them in a few surfaces and one mesh...
Like I said, I've only briefly looked at the command set:
https://www.appgamekit.com/documentation/home.html (https://www.appgamekit.com/documentation/home.html)
Entities are Objects in AGK but there is no createobject, only createobjectfromheightmap and the usual, cube, cylinder etc..
There is no createbone but you can access bones on a created mesh. Looks like you can also only create sprites/images from files loaded etc..
I may be wrong but looks pretty poor compared to what I'm used to.
Quote
Looks like you can also only create sprites/images from files loaded
You really should look at the examples that come with AGK before making inaccurate statements.
I don't know about 3d features because I've not used that side of things.
QuoteLooks like you can also only create sprites/images from files loaded etc..
You can grab parts of the screen and you can also create sprites in memory using memblocks. You can also render to texture both sprites and movies.
Quotebut there is no createobject
Any of these commands of use? - looks like there are commands to manipulate and create meshes.
CreateObjectFromObjectMesh ( objID, fromObjID, meshIndex )
GetObjectMeshSizeMaxX ( objID, meshIndex )
GetObjectMeshSizeMaxY ( objID, meshIndex )
GetObjectMeshSizeMaxZ ( objID, meshIndex )
GetObjectMeshSizeMinX ( objID, meshIndex )
GetObjectMeshSizeMinY ( objID, meshIndex )
GetObjectMeshSizeMinZ ( objID, meshIndex )
SetObjectMeshNormalMapScale ( objID, meshIndex, scaleU, scaleV )
SetObjectMeshUVOffset ( objID, meshIndex, textureStage, offsetU, offsetV )
SetObjectMeshUVScale ( objID, meshIndex, textureStage, scaleU, scaleV )
AddObjectMeshFromMemblock ( objID, memID )
CreateMemblockFromObjectMesh ( objID, meshIndex )
CreateObjectFromMeshMemblock ( memID )
GetMeshMemblockVertexAlpha ( memID, vertexIndex )
GetMeshMemblockVertexBlue ( memID, vertexIndex )
GetMeshMemblockVertexGreen ( memID, vertexIndex )
GetMeshMemblockVertexNormalX ( memID, vertexIndex )
GetMeshMemblockVertexNormalY ( memID, vertexIndex )
GetMeshMemblockVertexNormalZ ( memID, vertexIndex )
GetMeshMemblockVertexRed ( memID, vertexIndex )
GetMeshMemblockVertexU ( memID, vertexIndex )
GetMeshMemblockVertexV ( memID, vertexIndex )
GetMeshMemblockVertexX ( memID, vertexIndex )
GetMeshMemblockVertexY ( memID, vertexIndex )
GetMeshMemblockVertexZ ( memID, vertexIndex )
SetMeshMemblockVertexColor ( memID, vertexIndex, red, green, blue, alpha )
SetMeshMemblockVertexNormal ( memID, vertexIndex, x, y, z )
SetMeshMemblockVertexPosition ( memID, vertexIndex, x, y, z )
SetMeshMemblockVertexUV ( memID, vertexIndex, u, v )
SetObjectMeshFromMemblock ( objID, meshIndex, memID )
GetObjectMeshName ( objID, meshIndex )
GetObjectMeshPSSource ( objID, meshIndex )
GetObjectMeshVSSource ( objID, meshIndex )
GetObjectNumMeshes ( objID )
SetObjectMeshImage ( objID, meshIndex, imageID, textureStage )
SetObjectMeshLightMap ( objID, meshIndex, imageID )
SetObjectMeshNormalMap ( objID, meshIndex, imageID )
SetObjectMeshShader ( objID, meshIndex, shaderID )
Quote from: Steve Elliott on February 04, 2018, 18:39:35
Quote
Looks like you can also only create sprites/images from files loaded
You really should look at the examples that come with AGK before making inaccurate statements.
I don't know about 3d features because I've not used that side of things.
Like I said - I may be wrong but should not have jumped to conclusions after a quick schoofty.
So you and Qube are using AGK - excellent - how do you find it in general and syntax wise?
Quote from: Qube on February 04, 2018, 18:56:41
QuoteLooks like you can also only create sprites/images from files loaded etc..
You can grab parts of the screen and you can also create sprites in memory using memblocks. You can also render to texture both sprites and movies.
Quotebut there is no createobject
Any of these commands of use? - looks like there are commands to manipulate and create meshes.
CreateObjectFromObjectMesh ( objID, fromObjID, meshIndex )
GetObjectMeshSizeMaxX ( objID, meshIndex )
GetObjectMeshSizeMaxY ( objID, meshIndex )
GetObjectMeshSizeMaxZ ( objID, meshIndex )
GetObjectMeshSizeMinX ( objID, meshIndex )
GetObjectMeshSizeMinY ( objID, meshIndex )
GetObjectMeshSizeMinZ ( objID, meshIndex )
SetObjectMeshNormalMapScale ( objID, meshIndex, scaleU, scaleV )
SetObjectMeshUVOffset ( objID, meshIndex, textureStage, offsetU, offsetV )
SetObjectMeshUVScale ( objID, meshIndex, textureStage, scaleU, scaleV )
AddObjectMeshFromMemblock ( objID, memID )
CreateMemblockFromObjectMesh ( objID, meshIndex )
CreateObjectFromMeshMemblock ( memID )
GetMeshMemblockVertexAlpha ( memID, vertexIndex )
GetMeshMemblockVertexBlue ( memID, vertexIndex )
GetMeshMemblockVertexGreen ( memID, vertexIndex )
GetMeshMemblockVertexNormalX ( memID, vertexIndex )
GetMeshMemblockVertexNormalY ( memID, vertexIndex )
GetMeshMemblockVertexNormalZ ( memID, vertexIndex )
GetMeshMemblockVertexRed ( memID, vertexIndex )
GetMeshMemblockVertexU ( memID, vertexIndex )
GetMeshMemblockVertexV ( memID, vertexIndex )
GetMeshMemblockVertexX ( memID, vertexIndex )
GetMeshMemblockVertexY ( memID, vertexIndex )
GetMeshMemblockVertexZ ( memID, vertexIndex )
SetMeshMemblockVertexColor ( memID, vertexIndex, red, green, blue, alpha )
SetMeshMemblockVertexNormal ( memID, vertexIndex, x, y, z )
SetMeshMemblockVertexPosition ( memID, vertexIndex, x, y, z )
SetMeshMemblockVertexUV ( memID, vertexIndex, u, v )
SetObjectMeshFromMemblock ( objID, meshIndex, memID )
GetObjectMeshName ( objID, meshIndex )
GetObjectMeshPSSource ( objID, meshIndex )
GetObjectMeshVSSource ( objID, meshIndex )
GetObjectNumMeshes ( objID )
SetObjectMeshImage ( objID, meshIndex, imageID, textureStage )
SetObjectMeshLightMap ( objID, meshIndex, imageID )
SetObjectMeshNormalMap ( objID, meshIndex, imageID )
SetObjectMeshShader ( objID, meshIndex, shaderID )
Looks like the very chaps - thanks Qube.
QuoteSo you and Qube are using AGK - excellent - how do you find it in general and syntax wise?
Overall I really like it and it's put the fun back into coding. The language isn't to everyones tastes, especially if you are strictly an OO or die kinda coder. It doesn't have any zippy flippy language gymnastics features like Monkey 1 & 2 have but then again, I've never needed one of those funky methods to make a game.
I like that it has built in support for TexturePacker ( big time saver ) and the broadcast system for testing on mobile is a God send ( no need to faff about with certificates ), just broadcast and it's on your phone / tablet in a few seconds. It also has built in support for Spriter and Spine + tones of other stuff like 2D & 3D physics, tweening, networking, files, 2D & 3D particles. Plus the documentation is not too bad either.
It can be a bit odd in places, for example there are two methods for drawing on screen. A percentage system and the X / Y coor system. If you want to use the X / Y system then you need to set the virtual resolution beforehand. No big deal, I just found it odd having two draw systems.
Lists are also a little harder to setup than in Blitz3D as in you create a type and then you create an array of the type and use that. Couple more lines of code but hey ho.
Quote from: Qube on February 04, 2018, 19:31:08
QuoteSo you and Qube are using AGK - excellent - how do you find it in general and syntax wise?
Overall I really like it and it's put the fun back into coding. The language isn't to everyones tastes, especially if you are strictly an OO or die kinda coder. It doesn't have any zippy flippy language gymnastics features like Monkey 1 & 2 have but then again, I've never needed one of those funky methods to make a game.
I like that it has built in support for TexturePacker ( big time saver ) and the broadcast system for testing on mobile is a God send ( no need to faff about with certificates ), just broadcast and it's on your phone / tablet in a few seconds. It also has built in support for Spriter and Spine + tones of other stuff like 2D & 3D physics, tweening, networking, files, 2D & 3D particles. Plus the documentation is not too bad either.
It can be a bit odd in places, for example there are two methods for drawing on screen. A percentage system and the X / Y coor system. If you want to use the X / Y system then you need to set the virtual resolution beforehand. No big deal, I just found it odd having two draw systems.
Lists are also a little harder to setup than in Blitz3D as in you create a type and then you create an array of the type and use that. Couple more lines of code but hey ho.
Good to know - ta. Must get round to looking at this.
I think Qube summed it up quite nicely, and has used it far longer than I have.
I'll just add that using C++ and OOP languages for a while, it was a pleasant surprise to come to a simpler system that has put the fun back into coding. I agree with Qube on that.
I do find it a little bit quirky at times, but that is always going to happen if a system has evolved over several years (and name changes). And it's more wordy than I personally would like.