JayFoxRox
Active Member
When I was talking about plugins I actually meant classes or modules. Like the current system, but with stricter rules.
The system shouldn't have pre-defined platforms like it has right now, but things like video_ogl, video_ogles, video_gx, .. as you could just mix w/e you need for one platform (Just see how similar most systems are.. Pandora only needed its own renderer while its fine with something like input_sdl (which is input_pc right now)).
I also had a look at the current stage format but I would like to modify it even more.
I'm currently busy writing my own stage code (based on the existing one to some degree) which also accepts "stage options" (numeric values, strings, colors, ..).
These options could be used to load the current stage format for example, creating some backwards compatibility or for more powerful and artistic things like light colors of the stage.
OBJ as model format sounds fine to me (even if I'm not a friend of text formats, I like binary stuff more). I think its best if the mesh class would have a pointer where the renderer could store its own private data, then callback the renderer when a model is initialized, modified or unloaded so it can update the private data (a list with drawcalls, compiled mesh, padded vertices, .. whatever the renderer needs).
In the most simple case the game would request a "test.obj" which is parsed, the renderer gets the data passed in, changes its private data pointer to point to the raw data read from the file, the renderer would then use the immediate rendering to draw the mesh at runtime (like it does right now).
In an optimized case the renderer would be notified about new data from "test.obj", compile a vertexbuffer, generate the drawcalls and optimize the mesh structure, unload the raw data (unless the raw data are supposed to be readable / changeable afterwards) and only keep the mesh in the private data for fast rendering.
The same should happen for textures. Right now the renderer (video_pc.cpp for example) has to load the PNG file on its own while it would make much more sense to load the PNG in a texture class, then tell the renderer that a texture should be prepared for rendering.
How about waiting for the last midi note or just waiting a bit after the song has stopped?
The wrong start doesn't seem to happen anymore. However one thing I noted is that the loading bar sometimes has a duck in it, is that intended (http://jayfoxrox.bplaced.net/screenshot/data/1263720070-1.jpg)?
video_pandora.cpp is still REALLY dirty, I already started to clean it up, but there are still some stupid things in it. It should just stay where it is for now
However, are you on IRC or MSN so we can discuss design questions?
The system shouldn't have pre-defined platforms like it has right now, but things like video_ogl, video_ogles, video_gx, .. as you could just mix w/e you need for one platform (Just see how similar most systems are.. Pandora only needed its own renderer while its fine with something like input_sdl (which is input_pc right now)).
I also had a look at the current stage format but I would like to modify it even more.
I'm currently busy writing my own stage code (based on the existing one to some degree) which also accepts "stage options" (numeric values, strings, colors, ..).
These options could be used to load the current stage format for example, creating some backwards compatibility or for more powerful and artistic things like light colors of the stage.
OBJ as model format sounds fine to me (even if I'm not a friend of text formats, I like binary stuff more). I think its best if the mesh class would have a pointer where the renderer could store its own private data, then callback the renderer when a model is initialized, modified or unloaded so it can update the private data (a list with drawcalls, compiled mesh, padded vertices, .. whatever the renderer needs).
In the most simple case the game would request a "test.obj" which is parsed, the renderer gets the data passed in, changes its private data pointer to point to the raw data read from the file, the renderer would then use the immediate rendering to draw the mesh at runtime (like it does right now).
In an optimized case the renderer would be notified about new data from "test.obj", compile a vertexbuffer, generate the drawcalls and optimize the mesh structure, unload the raw data (unless the raw data are supposed to be readable / changeable afterwards) and only keep the mesh in the private data for fast rendering.
The same should happen for textures. Right now the renderer (video_pc.cpp for example) has to load the PNG file on its own while it would make much more sense to load the PNG in a texture class, then tell the renderer that a texture should be prepared for rendering.
How about waiting for the last midi note or just waiting a bit after the song has stopped?
The wrong start doesn't seem to happen anymore. However one thing I noted is that the loading bar sometimes has a duck in it, is that intended (http://jayfoxrox.bplaced.net/screenshot/data/1263720070-1.jpg)?
video_pandora.cpp is still REALLY dirty, I already started to clean it up, but there are still some stupid things in it. It should just stay where it is for now
However, are you on IRC or MSN so we can discuss design questions?
