Over my internet/tv/vehicle-less christmas break at my moms place, I added some more goodies to my ongoing sodium project, like:
-prefix operators in sodiumscript, like -(x/2) or !IsObjectValid()
-local variables. this allows function parameters, recursion, and of course avoiding global namespace variables modifying each other
-3do meshes and hierarchy are now loaded and rendered properly
-beginnings of animation system, currently playing keyframes of .key files
-loading .jkl level files. Not currently doing anything with the adjoins for C&P vis determination, but its on my todo list.

Cool. I likes it.

nice.. looks sweet

Wanna tell me what it actually does in non-nerd talk?

1. What's that stormtrooper standing on?
2. WHAT is that crazy flying orb robot thing?

Hes standing on nothing, gravity isn't enabled for any of these objects.

The flying orb thing is a little robot dood i made for testing 3do hierarchy and animation.

Pretty cool. I can see you've put a lot of effort into this.

Any particular reason why you put the $ after the name of the local variable? Seems like a strange convention to me. Looks pretty cool, even though I still think you should use lex/yacc. :p

what happens if I declare a local variable without a $ sign, eh precious

Something like this?



Code would execute and output:
Then you're dumb!

Using $ is kinda weird, but atleast he's not crippling himself by sticking with cog.

How would he cripple himself by 'sticking with cog'? If he's the programmer, he can do whatever he wants to the cog system if he so chose. :p

Right, so it's just used to resolve scope. Personally I'd prefer you skip the $ sign and just make the script not compile when you declare a local variable with the same name as a global one. That'll mean you'd need some variable declaration keyword instead of relying on implicit declaration - a good idea anyway because it makes scripts much more readable.

Using a $ is perfectly understandable (think php), but putting it after the variable is what's kind of weird. Looks very impressive; better than anything I've done.

[QUOTE=Hell Raiser]How would he cripple himself by 'sticking with cog'? If he's the programmer, he can do whatever he wants to the cog system if he so chose. :p[/QUOTE]
resize an array rofl

Updates on geometry rendering code




Some simple camera / sector collision detection.

The sector you are currently in is highlighted in green.

There's some very basic cell & portal testing going on, but it's just hacked in for right now; I'm playing with it, trying to get a good feel so I can write the actual algorithm. In the screenshot you can see blackness where there should be sectors. If you were to move forward into or nearer to the sector that has black adjoins, the sectors beyond those adjoins will be rendered properly.

Try it out for urself
http://binarydemons.com/~strike/files/se.zip

What's in that zip exactly?

I wrote exact visibility testing for the lighter plugin and sith2, so you can take a look at that if you want. I tried to run your program but it crashes without an error immediately after opening its two windows.

I'd definitely be interested in some help with the vis testing.

The reason the program exited immediately was because it couldn't find something it tried to load. JK should be installed to the default path, and the entire zip should be extracted somewhere, creating various subfolders.

Even more updates. Highly optimized some of the sloppy code that would/is used for portal testing. A couple hundred fps boost, ranges between 200-500 on my machine.

I expect an even higher framerate boost when I actually load geometry onto the graphics card and/or triangle-strip the polys (its still just sending coords to the card every frame).

Notice you can still see blackness where sectors should be drawn hehe
The real c&p vis determination will probably eat some fps, but its best to try and get things as fast as possible because I'm sure physics will rip the framerate to shreds (for a while at least).

I found that the full vis testing did add some overhead, but it was almost always a big win.

As for rendering jk levels quickly, they just have a terrible format that doesn't suit itself well to modern graphics cards...what I ended up doing was building a triangle list per material each frame (or better yet as the visible set of sectors changes). I stored vertices in a vbo on the graphics card, but kept the indices in system memory since they changed so frequently. End result was one call to DrawElements per texture for visible textures, and this was very fast.

I don't have JK in the default path; perhaps you could read the path from the registry.