| |
WVL
Registered: Mar 2002
Posts: 902 |
Pinball Dreams discussion forum
Hey guys/girls,
instead of updating my homepage all the time, I though I could open a new thread here instead. This will also allow other ppl to comment on the development.
okay, so whassup at the moment?
Well, Last month I completely restarted from scratch on the code. Why? Well, first I wanted to concentrate more on getting the game to run in less memory, also I wanted to focus more on accurate simulation of the ball and some small other things...
What I have done till now :
1 - spawned the ball ;-)
2 - added gravity to the surroundings, the gravity data is now RLE encoded, so it doesn't take up much memory anymore. Used to eat 20 blocks of memory, now I think a map would use 3-4 blocks..
3 - I changed the gravity routine to use polar-based vectors instead of cartesean, much more accurate!
4 - added a debug mode to the movement routines, you're able to pick up the ball with the firebutton and move it around. Let go of the button and you drop it on the table again.
5 - Worked on an accurate (within 1 'bradian' degree) direction calculation routine. This routine will be used for both friction calculations and calculating new directions after collisions. So it needs to be
6 - added a (simple) friction routine.
7 - I put a small preview on the web ;-)
get it at http://www.interstyles.nl/pinball.rar
okay, what am I up to now?
1 - increase the speed accuracy to 24 bit, I need this because the friction only affects speed in the last 3 bits or so, so it's not accurate at all..
2 - add spin to the ball, so it is allowed to roll.. (also gives effect to the ball like top-spin and such)
3 - dunno yet, I'll see what is the next logical step after that.. probably the new method of collision detection, dunno..
I'm thinking of putting the sourcecode online as ascii file, so everyone can check it out...
Suggestions? Questions? other stuff?
greets, Werner
|
|
... 163 posts hidden. Click here to view all posts....
|
| |
WVL
Registered: Mar 2002
Posts: 902 |
As for scrolling : It has been removed for now, but it's easy to add. All the necessary (REU) routines are ready, but as I was saying I'm trying to get it to run on a stock machine as well, so I'll have to add a linecrunch routine...
About the top border : the game only allows for a 64 char high table -> place the sprite in the upper border and it will read the gravity data from row 63,62.. etc, which are not defined yet :) only rows 0-24 (the top screen) is defined as to now... (IE - AFTER ADDING COLLISION DETECTION IT WILL BE IMPOSSIBLE TO GO IN THE TOP BORDER OFCOURSE :))
Werns |
| |
WVL
Registered: Mar 2002
Posts: 902 |
oh, btw, please don't mind the background 'picture' in the preview ;-) it was only meant to visualise the resulting gravity-force... about one minute work in photoshop and then some on my converter... |
| |
Nafcom
Registered: Apr 2002
Posts: 588 |
Hello there!
Okay, preview is great anyway, so thanks!
Great to see, that developing goes on! :)
One question: How about NTSC & PAL compatibility?!
Thanks in advance!
All the best!
Bye!
Joerg |
| |
WVL
Registered: Mar 2002
Posts: 902 |
well, it will be PAL, dunno if ppl will want to convert to NTSC? also I don't know if NTSC has enough cycles/frame to do all necessary calculations, it might be necessary to drop some realism in a possible NTSC version.. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
I dare say that the majority of the active NTSC users today have SuperCPUs. Just enable 20 MHz mode in the border and switch back to 1 MHz mode in the first irq and NTSC users will have plenty of cycles to catch up.
|
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Also, if you do all critical (but fast) stuff in IRQs and heavy calculations in mainprogram, running out of time doesn't matter that much (just momentary slowdown) |
| |
WVL
Registered: Mar 2002
Posts: 902 |
it runs either at 50fps or not at all.. I'll include a debug feature that will halt the game whenever all calcs cannot be done in one frame, and will write debug data to disk or something. This will allow me to see where speedups are in order. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
btw, what would you consider not-critical calculations? :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
"non critical" is everything that is not immediatly visible.... for example the actual scrolling _must_ be done each frame, else the screen goes jerky. the ball movement for example can be calculated taking a time-factor into consideration, so "frames" of ball-movement can be skipped when there is not enough time in current frame.... actually there are a lot of these kinda "non critical" calculations in a game, its just a little bit "different" to implement them this way. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
With doublebuffering, almost every main program task except color-RAM scrolling becomes not-critical. Basically, things that cause slowdown if they're missed, but won't cause outright ugliness onscreen, as raster interrupts keep things running. But this is just a different ideology, I won't lose my sleep if some frames are missed in some tight / action-full situations :) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 18 - Next |
