Doing 3D games on the Oric ?
Filled polygons?Algarbi wrote:Can this get any better?! \o/
Chema, i intended that the white frame around the play area should not be there. Even though it may mark the boundary of the game area i don't think it will be neccesary.
I also need to redesign the Power redirection Lever since the current version will expect frames for both the lever and the pointer above it.
There is some space in the bottom left corner incase you need more indicators.
The Fore and Aft shields have a light to the right of each bar. These have been designed to go red when a shield is low.
The square thing in top right should be changed a bit. I like the idea of a single indicator to show you the overall condition of the craft. If that goes red or amber (normally green or Cyan) then the player would look at the other panels to find the exact cause.
Finally i still want to improve the curve behind the radar disc, i have asked Ptoing for help here. He's a professional graphic artist so should give me some better ideas.
And dudes, don't limit your minds to the constraints of the Oric. Its constraints are there to be overcome!
Greetings.
Some advances (small, but important, imho).
Tweaked the contol panels and now they are more usable. Also started coding their behaviour, so shields, speed and missiles (including all the locking sequence), radar and scanner are all working.
Thanks to Twilighte for his impressive work in this area.
Also some bug hunting and small advances in code. Moved the 3d models to overlay ram (using over 9K now) to have more room in normal memory for other matters.
Finaly, added a suggestion from Dbug. I now use an alternate (and simpler) model for ships that are far away. Original Elite drew them as spots in that case. I am using a tetrahedron, which seems to work better and lets me keep them simplified when they are closer.
The improvement is quite important, as usualy you will have several ships far from you and only one or two nearby and in sight. So now with two far ships in sight, framerate is almost 7.7 fps and only drops to 5 fps when one of them is close enough. Playability has improved quite a lot this way.
I am, however, experiencing delays between keypresses and game reaction. These are quite annoying. I am not sure if they are caused by the game itself, as I notice the same when using other programs in Euphoric (such as HIDE) and also simply typing things on the oric screen. And sometimes I have to repeat the keypress to have any kind of reaction from the program. No idea what is going on here, but have to try more.
I would love to try with virtual PC 2004, which seemed to work much better, but don't know why the mapping of real folders into virtual disk units stopped working in my laptop running win XP.
And yesterday evening I was playing with the spectrum version of Elite, trying to get some inspiration and noticed that the screen updated showed some kind of motion blur, more noticeable on planets and suns, so I took a video and inspected some frames. Have a look:
So it seems that the speccy version (which uses double-buffer and not the eor trick for drawing lines) updates just half of the screen (odd/even scans) alternatively at each frame. I will try to do the same and see how it looks like, because that should speed things up a lot!
More to come...
Some advances (small, but important, imho).
Tweaked the contol panels and now they are more usable. Also started coding their behaviour, so shields, speed and missiles (including all the locking sequence), radar and scanner are all working.
Thanks to Twilighte for his impressive work in this area.
Also some bug hunting and small advances in code. Moved the 3d models to overlay ram (using over 9K now) to have more room in normal memory for other matters.
Finaly, added a suggestion from Dbug. I now use an alternate (and simpler) model for ships that are far away. Original Elite drew them as spots in that case. I am using a tetrahedron, which seems to work better and lets me keep them simplified when they are closer.
The improvement is quite important, as usualy you will have several ships far from you and only one or two nearby and in sight. So now with two far ships in sight, framerate is almost 7.7 fps and only drops to 5 fps when one of them is close enough. Playability has improved quite a lot this way.
I am, however, experiencing delays between keypresses and game reaction. These are quite annoying. I am not sure if they are caused by the game itself, as I notice the same when using other programs in Euphoric (such as HIDE) and also simply typing things on the oric screen. And sometimes I have to repeat the keypress to have any kind of reaction from the program. No idea what is going on here, but have to try more.
I would love to try with virtual PC 2004, which seemed to work much better, but don't know why the mapping of real folders into virtual disk units stopped working in my laptop running win XP.
And yesterday evening I was playing with the spectrum version of Elite, trying to get some inspiration and noticed that the screen updated showed some kind of motion blur, more noticeable on planets and suns, so I took a video and inspected some frames. Have a look:
So it seems that the speccy version (which uses double-buffer and not the eor trick for drawing lines) updates just half of the screen (odd/even scans) alternatively at each frame. I will try to do the same and see how it looks like, because that should speed things up a lot!
More to come...
when I first saw that spectrum screenshot I thought you had changed the fabulous controls from Twilighte 
Update: Not so easy, unfortunately. Did a quick test and it is VERY fast, but looks horrible. Looked again at the speccy version and it seems that they don't do something so simple.
Have a look at this screenshot:
First, it is difficult to pause the emulator and see the effect, so it is not "frame by frame". Second, as you can see in the picture, not all the screen is "half-updated", so they could be driving the update with interrupts. No idea.
Will study the problem.
Have a look at this screenshot:
First, it is difficult to pause the emulator and see the effect, so it is not "frame by frame". Second, as you can see in the picture, not all the screen is "half-updated", so they could be driving the update with interrupts. No idea.
Will study the problem.
I trust you can do it.
Suggestion:
- split the blitting routine in four: top half (even lines), bottom half (even lines), top half (odd lines), bottom half (odd lines).
- modify your blitting code so it keeps incrementing a value, with value & 3 giving you the number of the blitting routine to call.
- fix yourself a cpu budget in frames/second
- after each computed frame, do a loop from value to value+4 and call each of the blitting routine, starting from the last valid position of value. In the loop you test the framerate counter, and if it goes above your budget you exit the loop.
- so technically if a frame is very long to compute, it will only be partially blitted (1 thrd, one half, 2 third), and the next frame will continue blitting the rest of the buffer from the current position.
In short, when the game manage to update fast, it will blit most of the screen, if for some reason it struggles, it will blit less of it, but it will in average update all of the screen.
Does that makes sense ?
- split the blitting routine in four: top half (even lines), bottom half (even lines), top half (odd lines), bottom half (odd lines).
- modify your blitting code so it keeps incrementing a value, with value & 3 giving you the number of the blitting routine to call.
- fix yourself a cpu budget in frames/second
- after each computed frame, do a loop from value to value+4 and call each of the blitting routine, starting from the last valid position of value. In the loop you test the framerate counter, and if it goes above your budget you exit the loop.
- so technically if a frame is very long to compute, it will only be partially blitted (1 thrd, one half, 2 third), and the next frame will continue blitting the rest of the buffer from the current position.
In short, when the game manage to update fast, it will blit most of the screen, if for some reason it struggles, it will blit less of it, but it will in average update all of the screen.
Does that makes sense ?
Thanks Dbug, it does make sense. I have thought about doing something similar before, but never tried.
It is a very good idea.
On another note I have been solving many bugs, completing the gameover sequence, restarting the game, setting all the player data in contiguous memory (and keeping an initial status copy) with the saving/loading in mind.
A lot of progress indeed.
And I decided to do something I was a bit reluctant to. Post a video, so you can see how things are going. I hate this, because posting something on YouTube before the game is finished shows more what is missing that was has been already made. Anyway I thought that you could be interested, so...
http://www.youtube.com/watch?v=MCpR8ARSJco
Some faults are seen here, but also the current game speed and many details that are already there.
But I won't bore you more. Just have a look and let me know what you think, as usual.
Regards,
It is a very good idea.
On another note I have been solving many bugs, completing the gameover sequence, restarting the game, setting all the player data in contiguous memory (and keeping an initial status copy) with the saving/loading in mind.
A lot of progress indeed.
And I decided to do something I was a bit reluctant to. Post a video, so you can see how things are going. I hate this, because posting something on YouTube before the game is finished shows more what is missing that was has been already made. Anyway I thought that you could be interested, so...
http://www.youtube.com/watch?v=MCpR8ARSJco
Some faults are seen here, but also the current game speed and many details that are already there.
But I won't bore you more. Just have a look and let me know what you think, as usual.
Regards,
