As I filtered though what I wanted to see i began of thinking about certain things and decided I should make a list before I forget so I did:

http://www20.brinkster.com/sutabi/todolist.html

These are some of the things I would like try to incoperate maybe you have other ideas....

Also please dont responde with SOLID, since its relased is being delayed due to the owner wanting to not release it till his book if finished.

Also a small summery ton put together of what should be considered of the game engine is here

::me hopes people goto gamedev.net and beg on their forums to help blender's GE continue development::

Quote:

Also please dont responde with SOLID, since its relased is being delayed due to the owner wanting to not release it till his book if finished.

When did this happen? I was psyched that this was going to happen sooner rather than later and now this. Does anyone know if hes close to finishing the book? Man this is a bummer.

Anyway thanks for all the hard work and the update Sutabi. Keep up the good work.

I don't see how you equate using .tga's with multitexturing. Multitexturing is really nice for terrain, where you want to blend a repeating grass texture with, say, a repeating dirt texture. Doing a lot of this is really difficult without multitexturing. Also, consider where you want something to have an environment map combined with a regular texture (a car texture for instance). Currently, you have to make the environment texture a seperate mesh and size it a bit bigger. This can be problematic. Multitexturing would be a lot better. Consider adding it to your to do list:)

Also I'm still working on culling, just haven't been on it for a while and I don't remember what Im doing. Plus my dad is away for a week, and I can't do much without his help. Oh well, at least solid isn't back yet lol so we have some more time to implement it.

hehe ... already tried the gemedev.net begging thing ... noone seems interested in hacking into the blender source, everyone just wanna invent their own engine. it's a shame cause a a couple of the people hanging around there can really bust the development. oh, yes : go for the toon render first !!! i can continue my game once it will be functional (and then i'll will show the world my wonderfull talent... maybe... i think ... probably ...).

thanx for the effort
Koby

Saluk: some cards suppost multitexture while other would have todo 2 pass rendering...
The problem with Mutitextuing is that its going to have todo a limit becuse if every=one had state of the art card I see no problem with it.... but you'll have to rely on 2 passrendering for mulritexturing...stenciling (with includes refections shadows) require 2 pass rendering... so its a pick or choose. Although if a g-card supported multitexture gl extensions then rendering shadows and reflection wont be a problem with that....

Also most implications of multitexturing is RGB and then second texture A, unless you relie on blending. I i talked to Ton about like 2 months ago and told me not to really bother...

Now really only my 2 Eurocent (because I've got to get into my bed - have to work tomorrow): What about the alpha bug? This little annoying creature should be extinct even before adding new (rendering related) features.

in reply to some posts

"the alpha bug"
(I'd rather call it more like an unexpected situation... or something)
It would be VERY difficult to have an all-purpose solution for "the alpha bug"
for the moment it is possible to sort your faces manually, some of the time
[self-plug] http://www.geocities.com/z3r0_d/alphaSorting/ [/self-plug] (script there too)
but I would agree that it needs to be improved. (maybe do what my script does, but consider occlusion and create multiple objects for each way things need to be sorted? still would be a pain, and not a complete solution)

I would like more rendering options, such as a alpha test option associated with textures, so that I don't have to worry about "the alpha bug", instead the alpha channel will determine if the texture is, or is not transparencent at that pixel. (no translucency)

Oooh, can we have a viewport actuator?
http://www.blender.org/modules.php?op=modload&name=phpBB2&file=viewtopic&p=8115#8115

The Alpha is not the problem....

This is what you call "z-buffer fighting"

this can be fix a lot easier if ketsji did not render in 3 modes:
Primative->render
Primative Extended->render (there something that make the recalculations of normals)
3D Primative->render

if you notice thre isn't object rendering all it basicly does is take all the object sort them between these 3 render options and renders them.... the object dont get render themself... so simple just finding out wheather the object has alpha then figure out while object with alpha is further ways from the camrea then rendering will not work....

I'd, or someone else would nee to make another render mode
Primative_Alpha()
but before that sort oiut the object that have alpha then sort which is furthest from the camera.
The only problem I see as fixing that is I have yet found where the objects are assigned to these stupid render functions
________________________________
Edit:
(this is just a not to myself so i wonder forget)
getobjects->put verts in list & send drawing more-->sort render though render funtions->sort thought triangles and quads->render

Explanation of the different render funtions and why they are there:
IndexPrimitives_3DText || Used for Text Faces
IndexPrimitives_Ex || Used for Deformed objects (is there why recals arn't made to update collisions!?
IndexPrimitives || for the regular mesh stuff

need to add?
IndexPrimatives_Z || support for more then 2 alpha buffering
Edit Ras_MaterialBucket.cpp (and .h?) to apply the check of which mesh has alpha
KX_scene.cpp&.h sor t the objects (with alpha) from furthest->close from camera postion
(some file name

Frustrum culling is no biggie, really. I'm not the hottest with the maths, and I wrote a python script ages ago for forest generation that only made trees that the camera could see on any given frame. A simple way to fix the edge of screen clipping problem is to oversize the camera slightly in your visibility calculations.

z3r0_d:

I see you point on a view point actruator..... which I would see vry useful..... but your lacking some details.

One of the first things I've notice you that you want an actruator but... actuators are for objects. I would see a need for one for a World.... and thats where I see a need

As you all know its sometimes troblesome to init all the things in python so what I need to see done is a World Logic Bricks. It Basic Function it to Run only once, so then you can set up varbles at init as well as veiw points as well as other needs....

But then comes the gui issues, I can guess just using the exsiting realtime style but add a switch like in material where you can access world materials, so then sticking the functions for the world (thats already in the world buttons) into there.