Incbin and LoadTexture (OpenB3D)

BlitzMax Forums/BlitzMax Programming/Incbin and LoadTexture (OpenB3D)

RustyKristi(Posted 2016) [#1]
I tried this already with Import BRL.RamStream and no paths just straight "incbin::myimage.png"

Does Incbin works with LoadTexture, have not seen any example other than the usual LoadImage.

PS: sorry posted in the wrong category, I thought this was BRL module.


Brucey(Posted 2016) [#2]
It will only work if LoadTexture supports TStream.


RustyKristi(Posted 2016) [#3]
Thanks Brucey. Were there any attempts or snippets that I can follow relating to File handle to Stream conversion?


Kryzon(Posted 2016) [#4]
After looking at the source of OpenB3D (available here for easy search with the features of Github), LoadTexture always assumes it's a path to a real file in the hard disk.

If you don't want to modify the source to add texture loading by memory (which is what is needed, it's what Incbin is), you can try this untested thing:
Function LoadIncbinTexture:TTexture( file:String, flags:Int = 9 )
	If Not file.ToLower().StartsWith( "incbin::" ) Then Return Null 'Definitely not an Incbin file.
	
	'Seems to be an Incbin file.
	
	'According to https://github.com/markcwm/openb3d.mod/blob/master/openb3dlib.mod/openb3d/src/texture.cpp#L447
	'OpenB3D expects pixel data in RGBA order.
	Local pixmap:TPixmap = LoadPixmap( file ).Convert( PF_RGBA8888 )

	If pixmap Then
		Const TOTAL_FRAMES:Int = 1 'Loading a single-frame texture for now.
		Local texture:TTexture = CreateTexture( pixmap.width, pixmap.height, flags, TOTAL_FRAMES )
		
		If texture
			'Copy the pixels of the pixmap to the OpenB3D texture.
			'The second parameter of BufferToTex is the texture frame to load into, to be
			'used for loading animated textures from several pixmaps.
		
			texture.BufferToTex( pixmap.pixels, 0 )
		EndIf
		
		Return texture
	EndIf
			
	Return Null

End Function



RustyKristi(Posted 2016) [#5]
Thanks Kryzon, I'm more concerned with loading of B3D or Mesh files but that is a good start.

TeraPak code is now available for Blitzmax, uploaded by Yue and updated by the original author, though it still has issues with OpenB3D.


Kryzon(Posted 2016) [#6]
You will need to write C code for that and modify some functions in OpenB3D. If the author is still around you should send them an e-mail.


RustyKristi(Posted 2016) [#7]
I see that now when browsing through the module code, thanks.


Kryzon(Posted 2016) [#8]
It's C++ actually, I had my mind on C for some reason.
In any case, you'd need to identify an incbin file usage (like that example above) within the functions LoadMesh or LoadAnimMesh and then call a different OpenB3D library function, one that you write to read the B3D scene from memory instead of a harddisk file. You can use IncBinPtr and IncBinLen to get the information necessary from the file in memory.

But this leads to another point that I think supersedes all of this: should you really be worrying about adding functionality to a game engine?
- I assume you want to make a game. You have a game design, characters, a story. You don't want to keep modifying tools, you want to make your game exist and move on.
- At this moment in time there is no convenient way to get animated models exported to the B3D format. This is like a major red flag. The only way to get animated 3D content to use in your game is unavailable.

If you look at what commercial engines (be them free or not) do, they have what is called an 'asset pipeline', a convenient way for you to get 3D content from major sources (Maya, Blender etc.) into the engine.

You need to be very selfish about the tool that you use, you need to demand the best from it, because time is your most precious asset.
If the tool doesn't give you a fair return for the time you invested then there is something wrong.
It makes more sense to me to learn a whole different framework and language that already have this functionality (and all the other functionalities) that you will need to get your game to exist. That is the priority after all.


RustyKristi(Posted 2016) [#9]
Thanks Kryzon. this is all for testing purposes though I want to make a game asap.

I'm comfortable with what I have been doing with Max but I'm still open to other solutions down the road, like MonkeyX.

I don't have any problem with the asset pipeline, the incbin part is just something extra.

You need to be very selfish about the tool that you use, you need to demand the best from it, because time is your most precious asset.
If the tool doesn't give you a fair return for the time you invested then there is something wrong.
It makes more sense to me to learn a whole different framework and language that already have this functionality (and all the other functionalities) that you will need to get your game to exist. That is the priority after all.


Actually, it's quite the opposite. I'd rather focus on my game code and worry about the pipeline later. I had other engines before and can't make a simple game, finally settled for Blitz and the rest is history. Since you can add C++ with BMX through modules I can worry about that later.


Yue(Posted 2016) [#10]
@RustyKristi

What I think is that if you want to make a game best is gold development environment, which aims to make it easier, it's what I think based on my experience , I am not a programmer , but what has happened to me is that my projects are held back by issues how are you , where two forms exist , one the slower learn to make everything from scratch with custom code , or wait for a kind soul to help us with mdoulos , in this process you learn a lot , but not reached goal of making the game, something that is usually not as painful as for example in 3d unit. Now, I think I like you is happening in epaquetar aspect of the game files in BlitzMaz , but eventually is a learning process with an excuse to make a video game, but I guess that 's the fun . Now the case is that I will use xors3D in Blitz , as the packager is supported.


RustyKristi(Posted 2016) [#11]
As a new blitzmax user, that is to be expected and yes I am having fun with it that's the important part. You can't force yourself to be productive to a toolset with all that bells and whistles at the same time you are not comfortable with it.


Now the case is that I will use xors3D in Blitz , as the packager is supported.


Good for you. :-)

PS: Now that you have shifted to Xors3d, maybe you can release your Bullet Physics Ragdoll code? I'm still having trouble getting a ragdoll to work on a b3d model. thank you.


Yue(Posted 2016) [#12]
What I mean is that I feel more comfortable with Blitz3D , to end continuous operation. I would like to focus on BlitzMax but the learning curve at the end is a bit more difficult. In the end what happens to me it is I'm doing unfinished projects , but always learn something new. And when I'm not in Blitz3D , I'm in C #, or otherwise in BlitzMax , maybe someday succeed in making something. In this case after being in BlitzMaz and go to C # I understand a little better programming = )


RustyKristi(Posted 2016) [#13]
Making a game is one of the main goals why we are here. If you are comfortable with Blitz3D then why not finally make a game using it.

The learning curve for Blitzmax is not that all hard esp. if you are already familiar with B3D. It's the extending of modules that will need you to have some background with C++ or modular programming.

And of course, Brucey's NG version is something new and is a work in progress but aims to be modern and next gen as it claims.

This is getting off-topic btw..