lerabot wrote:
Like I said, I never even loaded a 3D model into KOS. I merely adapted the export script to work with blender current API.
There are examples for drawing 3D geometry in kos/examples -> pvr and kosgl. There is no middleware for rendering scenes or 3D models, however. So yeah, most homebrew devs just make 2D games and your middleware would make it more like for people to try making simple 3D games.
lerabot wrote:
This would of course not necessarily mean it is all loaded at the same time, but that the exported object could contain some LocRotScale infor of the original scene.
This is the stuff that should be part of your spec.
lerabot wrote:
By reading the topic you linked, I saw that PH3NOM engine used some quake format. I could adapt a blender script to work more toward that file format.
He doesn't seem to be using that anymore, but he's also skilled enough to work on his custom solution. You should think about beginner/intermediate programmers who would otherwise not make a 3D game instead. People who won't be making the next Sonic Adventure (3D games with 3D gameplay take certain math skills etc), but 3D games with 2D gameplay (instead of drawing sprites they draw 3D models on a 2D plane). Before we talk about making complex games, we should talk about making 3D games at all.
Scene formats can also be extremely complex, and I suggest you think about the compromises and the feature cut-off you want to make.
You could have a BSP-tree based scene like Quake or a portal-based scene ("rooms" linked by "portals/doors"), no support for either (just a single huge mesh), support for both..
You could have AI waypoints or navigation meshes.
You could have collision volumes completely separate from displayed geometry or just for volume triggers and and and..
Try to come up with the kinds of games people are likely to make and cater to those needs. If unsure, ask what the community wants to work on and offer support.
When possible, allow future extensibility, but don't overthink it.
An example of common extensibility for binary file formats are chunk-based file formats, where you have
Code: Select all
[Version=1.0]
[Chunk_Type=4|Dynamic_Objects][size = 5 kilobytes][5 kilobytes of data]
[Chunk_Type=10|Collision_Volumes][size=256 kilobytes][256 kilobytes of data]
[Chunk_Type=5|Navigation_Meshes][size=128 kilobytes][128 kilobytes of data]
[Chunk_Type=3|Waypoints][size=128 kilobytes][128 kilobytes of data]
[Chunk_Type=40008|bogglez_Fog_Volumes][size = 5 kilobytes][5 kilobytes of data]
A file parser can then just ignore any chunks it doesn't understand, because the size of its data of unknown format is known. This also allows you to have waypoints + navigation meshes or just one of them. The parsing code is then just
Code: Select all
while(pos < end) {
type = read_int(pos);
pos += sizeof(Chunk_Type);
size = read_int(pos);
pos += sizeof(Chunk_Size);
switch(type) {
case CHUNK_TYPE_NAVIGATION_MESHES:
parse_chunk_navigation_meshes(pos, pos + size);
// ....
default: puts("Warning: unhandled chunk type in scene");
}
pos += size;
}
For inspriation, you may want to look at simple scene formats like for Super Mario 64.
lerabot wrote:
In the end I'd be just happy to contribute to the dreamcast dev scene while learning more about KOS stuff.
Let's go