MaxCoderz

Geeze, this just keeps getting better and better!

I've added a "look at" routine for the matrices - it's now possible to track an object as it moves around.

You can try it out for yourself here. The cobra starts off behind the camera. When you go into object control mode (press ENTER) the camera will start tracking the cobra. If you switch back to camera mode, the camera will assume it's previous orientation.

Screenshot - first half with stars on, second half with stars off:

This looks a lot more professional already than many old PC games.

qarnos wrote:Screenshot - first half with stars on, second half with stars off

How come stars cause such a performance hit?

CoBB wrote:This looks a lot more professional already than many old PC games.

qarnos wrote:Screenshot - first half with stars on, second half with stars off

How come stars cause such a performance hit?

Partially because I'm lazy, and partially because there's still a lot work to do even just to display a point.

There are 120 stars in the demo - 15 "raw points" mirrored across all three axis' to produce the full 120. That comes up to about 57,000 T-states for each frame.

The actual star code is also pretty badly written - It was done as a hack to allow you to get a better idea of your orientation. The main point I can think of is that the culling code tests each star against every plane, regardless of whether one of the earlier tests failed. I should really fix that. I'd estimate I'm wasting ~150 T-states per star on average. That adds up pretty quickly.

qarnos wrote:*interesting explanation*

Nice. I've tried interlacing in the past but when I tried to modify fastcopy to update the lines horizontally I failed horribly then failed again trying to rewrite an lcd upate routine (but I couldn't make it independent of the lcd wait thingie).
This is encouraging me to try that again.

I've just had my first success running the library as a flash library. All it did was load the identity matrix, but it worked

The loading code is pretty small - the program has to look-up the application using _FindApp and then set the ROM page by outputting to port 6. It's about 40 bytes of "boilerplate" code in total, which gives you access to the whole library

The only problem will be calling shell routines - it can be done but requires disabling interrupts, paging the shell in, calling the routine, then paging back.

I have a free weekend this week, so I might be able to put out an early alpha version of the actual library, which will at least let you have a play around with it and import simple (no depth-sorting) models.

If you're wondering why I am going the flash-library route - the latest version DEMOCUBE had code running up to $BFD0

OK - I have a mostly functional pre-alpha-preview-beta version of the library functioning. You can download it here

Here's a basic rundown of the contents of the file:

bin/aether.8xk - the engine
bin/aldemo.8xp - the cobra demo

src/aether.inc - include file for the engine
src/aldemo.asm - the source for the demo

tools - stuff used to assemble stuff
makedemo.bat - an assembly batch file. Usage is makedemo filename[.ext]. The source must be in the src directory and the output will be placed in bin.

doc - really crappy not quite up-to date documentation.

models/obj - wavefront .obj files of several elite ships.
models/asm - compiled versions of the models
models/makeall.bat - batch file to create the .asm models from the .obj files.

The only thing worth mentioning is tools/import.exe. This is a really bad barely functional object converter (obj to asm). Input and output are through stdin and stdout, so to run it you would type:

import < input.obj > output.asm

It has one switch, -r, which causes it to produce polygon normals in the other direction - so if your object looks inside out, use this.

import will only use backface culling for visible surface determination, so no complex models can be created. Also, the faces are assigned whatever dither pattern the imported feels like - there is no way you can control this.

Also, it wont work on most .obj files because it doesn't parse them properly. It should work on files produced by Wings3D, so if you have problems, download Wings3D, import your model, then export it

All of this is still work in progress, so a lot of things will change. This release is just for anyone who wants to try and tinker with it a bit.

The engine uses appBackUpScreen for it's variables for now - until I can find somewhere more appropriate - so don't touch it.

Here's the demo running the "Boa" model.

This is really incredible work, I've never seen such attention to detail in a library before!

Though I don't have the time to experiment with this in the short term, I'm wondering whether this could tie in well with the missing graphics API problem I have with BBC BASIC.

Lots of documentation and source commenting, that's already very nice and inspiring for a pre-alpha-preview-beta

out of curiosity, how many poly's was the Cobra model? I'm kind of tempted to try and export some of my models for the Torque Game Engine to here, just to test.

elfprince13 wrote:out of curiosity, how many poly's was the Cobra model? I'm kind of tempted to try and export some of my models for the Torque Game Engine to here, just to test.

Sorry I haven't been around lately. I've been working on some neural network stuff which has been eating all my time. (NNet's are fun )

The cobra model (compiled version found in the models/asm directory) contains 26 vertices and 19 faces.

I created a sphere with 114 vertices and 128 faces and it ran surprisingly fast. I can't remember exactly, but I think it was 10-15 fps on my SE calc.

I need to dig up this stuff and start working again.

I'm glad to see you're still around and thinking of this project. What are your next plans?

benryves wrote:I'm glad to see you're still around and thinking of this project. What are your next plans?

Ummm... well, I guess the first step is to try and figure out where I was up to

I know the documentation and conversion tools still need a lot of work. The API also needs a bit of fleshing out. The bones are all there, but I need some more high-level stuff. In the state it is currently in I would be surprised if anyone other than myself could piece together enough of it to get a usable program.

So I guess I have some work to do.

I've been trying to get back into this project again, and after spending 15 minutes figuring out how to get the thing to assemble ( ), I decided to take a video of it running on my 84+.

If you haven't seen it running on a 15mhz calc before, it is actually quite smooth - averaging around 30fps.

http://www.youtube.com/watch?v=5LzzKc9X2Ms

Wow, nice to see you're getting back into the project. Very smooth video, too.