MaxCoderz

Whoa... *stares*

Load New Commander (Y/N)?

A really impressive demo, as always; even more impressive considering the way that the model has been imported!

O.O nice!

Whoa, I'm totally impressed qarnos! The FPS is incredible given the amount of detail. Also cool to see that drawing/clipping/culling issues seem to have been resolved now.

Is anyone aware of games or applications using this library?

Duck wrote:Also cool to see that drawing/clipping/culling issues seem to have been resolved now.

Well, mostly resolved. It won't crash but I'm aware of one case where things wont quite look right.

Is anyone aware of games or applications using this library?

Not yet, since the only source release available is from several years ago

I still have some work to do on the model conversion tools to make it useful, but hopefully I'm not too far away from being able to release something usable.

O_O.

%!H!OPH!*(Y!@! That is incredible!

Even if you dont have the time to commit to a game, a simple model viewer would be awesome on its own .

tr1p1ea wrote:Even if you dont have the time to commit to a game, a simple model viewer would be awesome on its own .

Well, that's the plan for the moment. The initial release will just be a basic model viewer - maybe someone else will be able to make a game out of it. I wouldn't mind taking a crack at Elite, though. Expect a release sometime in 2015

Here's an updated version of the demo which you, in particular, might enjoy. It's an experiment in greyscale stars... sort of. I basically turn the stars on and off every frame. It needs to run on an SE to get a high enough frame rate to have the desired effect, but looks ok.

It also fixes a problem with the object sometimes jittering all over the place when you roll the camera, like you saw in the first screenshot a few posts back.

I've just been playing around with some basic lighting effects and it looks promising, especially given how little work went into it Still a little way to go though to get it working how I would like.



There are two lighting methods: point source and infinite source.

Infinite source just takes a vector representing the direction the light is coming from.

Point source takes a point in world-space and calculates the light vector from this point to the object. The vector is only calculated to the centre of the object, not each vertex (for obvious reasons), so it won't look quite right when an object is close to the point source, but it is a good approximation.

Only one light may be defined, although it can be changed in between objects if you desire.

It isn't as time consuming as the frame-rate in the screenshot suggests - the coriolis station from the other demo is still there - slightly off screen - eating up my t-states.

Lighting too? Oh, how you spoil us. Looks excellent!

How are you calculating the dither pattern?

benryves wrote:Lighting too? Oh, how you spoil us. Looks excellent!

How are you calculating the dither pattern?

I have 9 8x4 pixel patterns set up, from 0/8ths to 8/8ths coverage. The dot product from the shading calculation gives a value between 64 (fully lit) and 0 (not lit). Since the patterns are stored sequentially in memory and are each 4 bytes, I just rotate the value right one place and mask out the two lowest bits to give a byte offset into the pattern array.

It is a little buggy in the shading - it doesn't seem to be calculating the offset correctly, hence the patterns seem to shimmer a bit, but I didn't get a chance last night to investigate it.

Unfortunately, I am going to have to redo some of the model rendering code to be able to elegantly handle lighting. This was just a hack built on top of the backface culling code, since they essentially do the same thing anyway.

A less buggy version of lighting. I just need to add support for an emission value now.

Wow, looks great and runs smooth! X-Wing 83 maybe? .

qarnos wrote:I just rotate the value right one place and mask out the two lowest bits to give a byte offset into the pattern array.

Does it look worse if you don’t mask out the last two bits? I can imagine that a clever dither pattern could allow achieving finer shades that way.

CoBB wrote:

qarnos wrote:I just rotate the value right one place and mask out the two lowest bits to give a byte offset into the pattern array.

Does it look worse if you don’t mask out the last two bits? I can imagine that a clever dither pattern could allow achieving finer shades that way.

That's not a bad idea!

What do you think:



Edited to add:

If anybody wants to try this on-calc, you can download the file here.

There are also two new keys: '(' and ')' will increase/decrease the size of the projection window. (On PindurTI, use '[' and ']')

I was doing some work today and deleted some code I shouldn't have, but it did produce a pretty cool screenshot

One of the techniques I am using to pick up some speed with sending data to the LCD is to keep two buffers - one for the current frame, and one for the last - and only send the bytes which have been altered. It's a kind of "dirty rectangles" scheme.

This screenshot illustrates it quite nicely. The code I removed (and quickly replaced!) was the code that cleared all the buffers at the start of the program to ensure everybody agrees on what is currently on the LCD. Without that code, you can actually see which parts of the LCD are updated.

Totally pointless, but it looks cool: