Progress Thread - New demo - Cobra Mk III (18-May-08)
Moderator: qarnos
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
Well, mostly resolved. It won't crash but I'm aware of one case where things wont quite look right.Duck wrote:Also cool to see that drawing/clipping/culling issues seem to have been resolved now.
Not yet, since the only source release available is from several years agoIs anyone aware of games or applications using this library?
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.
"I don't know why a refrigerator is now involved, but put that aside for now". - Jim e on unitedti.org
avatar courtesy of driesguldolf.
avatar courtesy of driesguldolf.
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 2015tr1p1ea wrote:Even if you dont have the time to commit to a game, a simple model viewer would be awesome on its own .
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 don't know why a refrigerator is now involved, but put that aside for now". - Jim e on unitedti.org
avatar courtesy of driesguldolf.
avatar courtesy of driesguldolf.
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.
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.
"I don't know why a refrigerator is now involved, but put that aside for now". - Jim e on unitedti.org
avatar courtesy of driesguldolf.
avatar courtesy of driesguldolf.
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.benryves wrote:Lighting too? Oh, how you spoil us. Looks excellent!
How are you calculating the dither pattern?
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.
"I don't know why a refrigerator is now involved, but put that aside for now". - Jim e on unitedti.org
avatar courtesy of driesguldolf.
avatar courtesy of driesguldolf.
That's not a bad idea!CoBB wrote: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.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.
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 don't know why a refrigerator is now involved, but put that aside for now". - Jim e on unitedti.org
avatar courtesy of driesguldolf.
avatar courtesy of driesguldolf.
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:
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:
"I don't know why a refrigerator is now involved, but put that aside for now". - Jim e on unitedti.org
avatar courtesy of driesguldolf.
avatar courtesy of driesguldolf.