sparrow3D - multi platform game engine


Quick question, and it's not really something I need at the minute, but are you going to support "rigged" 3D models? or some other method of animating. I don't really know what's involved from both the modeller side, nor the engine side.


Edit:


I also noticed there's a couple of Alpha calls in the primitives.Though I'm guessing this is for the Colour Key when used on 3D meshes? Or could we use them for alpha blending?
 
Last edited by a moderator:
The alpha calls are for SDL, so it doesn't draw pink pixel. You can't use blending with it ;-)


But as I will mention later (I am writing a documentation at the moment) some sparrow calls WILL allow "real" blending, if you deactivate z-Test and z-Set - in fact it's just SDL Surface blitting. ^^


No, I don't support some kind of more complex 3d format. But unlike VBOs in OpenGL, you are always able to manipulate the raw data of a mesh. For easy animations I would guess to export the parts of your to animate object one by one, and using the default sparrow calls for changing the orientation of each. Example:



Code:
spMesh3D(body,0);

spTranslate(SP_ONE,0,0);

spRotateX(rotation);

spMesh3D(arm,0);


greetings,


Ziz
 
The alpha calls are for SDL, so it doesn't draw pink pixel. You can't use blending with it ;-)
Thought so...

But as I will mention later (I am writing a documentation at the moment) some sparrow calls WILL allow "real" blending, if you deactivate z-Test and z-Set - in fact it's just SDL Surface blitting. ^^
Ohhh, sounds good. I remember when we last spoke about alpha blending, you were concerned on rendering time. But if we get some blending tools, that'd be great.

No, I don't support some kind of more complex 3d format. But unlike VBOs in OpenGL, you are always able to manipulate the raw data of a mesh. For easy animations I would guess to export the parts of your to animate object one by one, and using the default sparrow calls for changing the orientation of each.
Yeah, figured that was the only way to do it. Only asked because I'm not much of a 3D modeller, just I was just looking at what was available.


Thanks
 
Tried compiling the tests on 64bit linux, getting segfaults from the font stuff. Known issue?
Torpor mentioned something similar here, guess nobody's looked at it yet
 
Last edited by a moderator:
I do see parts that assume 32 bit address space, for example in spFontGetLetter we've got



Code:
if ( result != ( void* )( 0xFFFFFFFF ) ) //Found
 
I do see parts that assume 32 bit address space, for example in spFontGetLetter we've got



Code:
if ( result != ( void* )( 0xFFFFFFFF ) ) //Found
Yep exactly, Ziz is actually aware of those problems, just not able to properly test them atm.


Feel free to submit a patch though (if you find the time, Ziz will get to it eventually I guess).
 
Yeah, it's a shame, that I have no 64 bit system to test - and my 64 bit linux vm craches for unknown reason (other 64 bit OS work fine with my 32 bit host).


Furthermore I have no internet at home at the moment, so it's hard to even react to problems...


As pmprog and foxblock mentioned, 64 bit incompatibility is known and on the To Do. Maybe I should just use the 64 Bit university server.


However your mentioned code, bZar, is very 32 bitish - you are right - but the chance, that a 64 bit application uses the pointer 0xFFFFFFFF is very very small, so in in 18446744073709551615 of 18446744073709551616 cases it should not crash because of THIS deficiency in design...


But if someone could figure out, why it doesn't work on 64 bit, feel free to pull fixing commits :)


greetings, Ziz
 
In the above snippet of code, could we not switch 0xFFFFFFFF to (-1)? That will always equal the max 0xFF count on 32 and 64 bit systems


B-ZaR, what 64 bit platform are you running? I might try and set one up this weekend in VirtualBox and have a dig around.


Edit: BTW Ziz, sorry, I've still not tested your lighting fix. I'll test that this weekend too. Cheers
 
Last edited by a moderator:
pmprog: at the moment I'm running Kubuntu. I'll be switching back to Arch once radeonsi drivers support my GPU :)
 
Cheers, I'll have a gander. I'm assuming you're running KDE in Kubunto then? What were you building the project with? Code::Blocks?


I'm sure I won't need to mimic your dev env totally to reproduce it, esp' if torpor had a similar issue, but gives me some direction when installing it
 
Funny but true, I fixed that one point and now it works.


KDE, yes.


I'm building Sparrow3D with the included Makefile for the tests, but I'm actually using it to build foxblock's Project4, for which I use cmake (I posted the CMakeLists.txt in the thread)
 
Last edited by a moderator:
Nice. Glad it works! Also saves me building a VM ;)
 
Hey, foxblocks project4 is getting me new sparrow3d users. :D


Fine, that it seems to work. All tribut the finder, so feel free to commit and pull request, bZar. :)
 
Thanks :)


I hope it works for everyone. I will try to mention 64 bit architectures in the future. ^^
 
Always nice to see a new, promising engine. :)


Suddenly I have a vision about a 3D Pandora game, hack'n slay, random generated dungeons made out of variable pieces for endless fun...maybe I just play to much Diablo 3 these days... :D
 
Good morning, folk.


It happened a lot in the past months. First of all, I added a new example to sparrow3d. I saw this in a lecture and HAD to implement is. This are 15 wheals, which move in thereselfs... Hard to explain. Just have a look and get crazy. ^^

https://www.youtube.com/embed/GhxAp6qAKYQ?feature=oembed

Since my last post here I added ~50 commits, foxblock did 7 and pmprogs keeps the code always compatible with Visual Studio. I did not post about every change here, because just reading, that I added this or that is very boring for not developing people and developing people can follow my github-repository.


But because I made a little video about my new example today, I will talk about the changes we made, too.


First of all, of course I fixed a LOT of bugs. E.g. the main loop is now much faster. Just because of a small error in the time handling... Furthermore I improved the code and made it easier to fix and change.


But of course I also implementing fancy new stuff.

  • I added utf8 support. That means: Geman letters like Ä or ß or French letters like á (please let it be a French letter - I have no idea about this language ^^) are now possible. I changed the font API a bit, too. I hate API changes, but it was necessary.
  • foxblock did a lot for keyboard input. It does not really make sense, that you have to choice letters with your D-Pad and selecting it with a button (like in puzzletube) if you have a full functional keyboard like the pandora. So he started to implement functions for easy accessing entered strings. It is working fine and is pretty fast. The next tasks (of me) will be to add a screen keyboard for devices with only a touchscreen and some other kind of keyboard for devices without touchscreen.
  • Also I added a transparent surface cache. Thanks to foxblock for some ideas and criticism. I think without him the surface cache would be a bit weird to understand. Now it should be easy to use without thinking about a cache in the background everytime.
  • For another project I make right now, I had to improve the sprite engine. It is now possible to load sprites with different animations from a file. :D testsprite.c shows, how to use it.
  • Because the wiki pages grows very slow I added incode header comments for every function defined. So if you are not sure, how a function works exactly: Have a look to the header file. ;-)



Of course I did some optimizations again. ;-) I like #defines :>


So, if my code is working quite good (especially with Visual Studio) and is not slower (I did not test the latest changes on my gp2x), I will tag this as version 1.2. :D


greetings,


Ziz


PS: ALL GLORY THE WHEAL CHAIN!
 
Back
Top