just wondering if anyone minds taking over the ps2dev portion of my engine over ?
Im focusing on the core and other platforms, so I need some help to keep the ps2dev verision working.
its at http://www.tweakoz.com/orkid/
I was using a linux RTE devkit with a strange mix of scea libs and ps2dev libs, so the first thing in order would be get rid of any scea lib code (there isnt much)
just fyi, the engine also works as a tool, so you can build a version for linux, or windows that will build data for the ps2 version using the asset filtering mechanism - it basically can convert vertex buffers to dma chains, and soundfonts to vags (with loop resampling!), among other things - the soundfont portion does need encvag.dll though.
skinned vertex formats for the ps2 havnt been implemented yet, but the code to clusterize vertex buffers based on bone groups is in there.
If so please let me know, thanks ?
mtm
michael@tweakoz.com
http://www.tweakoz.com/portfolio/
anyone mind taking over the ps2dev portion of my engine over
When you say "it has to move from sce to ps2dev's libs", does it mean "grunt, easy work" ? Because then, that shouldn't be too difficult to handle :P
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.
Well, for me, I see
"Media Engine / Prototyping tool / Swiss Army Knife."
A bit later, I see "object oriented" and "scripting". So, I guess this is some big class collection of various graphical and sound tools, all of them containing serialization, script bindings, etc. Should let you toy with various primitive stuff very quickly, in order to help designing solid C or C++ code afterward, by derivating the formulas from the scripting interface to your whole code. You could even use it as a whole stand alone library, and build some non-time-critical tools around it.
"Media Engine / Prototyping tool / Swiss Army Knife."
A bit later, I see "object oriented" and "scripting". So, I guess this is some big class collection of various graphical and sound tools, all of them containing serialization, script bindings, etc. Should let you toy with various primitive stuff very quickly, in order to help designing solid C or C++ code afterward, by derivating the formulas from the scripting interface to your whole code. You could even use it as a whole stand alone library, and build some non-time-critical tools around it.
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.
thats ok, I am too. ;>Thanks, pixel! Now I'm even more confused.
I know its vague.
the closest analogy i can think of would be SDL, but im not sure if that has
introspection built in, and im sure SDL does somethings orkid doesnt do yet.
what it really is is the tool library I have been using off and on since 1996 (on IRIX back then), added to and generalized since then.
its not a game engine because there's no physics and very minimal AI (basically an actor/fsm/avatar class) and no basic gameplay built in.
mtm
Also, one of the reasons it is so vague is because I have used it for so many varied things.
With the small amount of time that I have to dedicate to this I just began to notice its much more efficient for me to maintain 1 medium sized piece of software vs many small pieces of software, hence the broad scope.
the OOP buzzwords will just let me focus on the idea rather than spend time implementing common things like loaders, savers and editors. Although I should mention the (de)serializer is still a work in progess.
as far as 'time critical' stuff the display driver reached 100+fps at 5 million polys a second textured without much optimization (on XBOX), not peak I know, but perfectly adequate for some uses. Also optimization would have needed to be done at the scene graph layer, not the display device layer. I never did get to benchmarking the ps2dev verson though ;>
I can say I think the 'engine' is pretty efficient at what it does. the most cpu/memory bound things I can think of is the use of STL, but its typically
used in places which wont affect performance critically. I think I have chosen a decent balance of flexibility vs performance for what I want to use it for.
mtm
With the small amount of time that I have to dedicate to this I just began to notice its much more efficient for me to maintain 1 medium sized piece of software vs many small pieces of software, hence the broad scope.
the OOP buzzwords will just let me focus on the idea rather than spend time implementing common things like loaders, savers and editors. Although I should mention the (de)serializer is still a work in progess.
as far as 'time critical' stuff the display driver reached 100+fps at 5 million polys a second textured without much optimization (on XBOX), not peak I know, but perfectly adequate for some uses. Also optimization would have needed to be done at the scene graph layer, not the display device layer. I never did get to benchmarking the ps2dev verson though ;>
I can say I think the 'engine' is pretty efficient at what it does. the most cpu/memory bound things I can think of is the use of STL, but its typically
used in places which wont affect performance critically. I think I have chosen a decent balance of flexibility vs performance for what I want to use it for.
mtm
yes for the most part.pixel wrote:When you say "it has to move from sce to ps2dev's libs", does it mean "grunt, easy work" ? Because then, that shouldn't be too difficult to handle :P
Now the bad news, over the course of this year I switched from using separately bound vertex and pixel shaders to a unified FX shader (like HLSL/CGFX techniques). I didnt finish this for PS2Dev.
This will mainly be copying over some TinyXML code from the GL driver and deciding how you will bind VU programs with this.
(my thought was just to reference a VU binary as the shader code versus shader source in the GL version, but if you want to call a VU assembler at runtime then have at it ;>). Then you will need to map parameter bindings to VU registers - not as hard as it sounds if you use the GL_ARB version as a reference. If you need to modify the script layout for this then so be it. At the end of this, you will basically have 'techniques' working for PS2.
mtm