|
Slightly cold news on page 10! Phlamey breaks the server. |
|
This is a long thread. Click here to view the threaded list. |
|
Jeffrey Lee |
Message #72594, posted by Phlamethrower at 03:50, 10/12/2005, in reply to message #72593 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Anyone know what kind of voodoo you need to do to change the CD playback volume? |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #72595, posted by Phlamethrower at 03:56, 10/12/2005, in reply to message #72594 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Ah, CD_SetAudioParms. Thanks, !Amp.
Thamp.
*hunts for documentation* |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #72610, posted by Phlamethrower at 01:41, 11/12/2005, in reply to message #72595 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
One of these days, I shall add the car movement code and car-car, car-world collision detection, so that I can actually go driving.
But today probably won't be that day, because I'm busy tweaking code
There's a couple of ped movement issues I want to sort out related to jumping (Which I'll probably solve by rewriting the jumping code entirely), as well as some tweaks to the sound system concerning the volume & balance of ped/car/object sounds.
Plus there's an ever-increasing list of commands I have to add to the script code, so I may have a go at some of them, as well as the additions I'll have to make to the car definitions to contain all the handling related info. |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #72662, posted by Phlamethrower at 14:27, 12/12/2005, in reply to message #72610 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
*does some research, GTA 2 stylee* |
|
[ Log in to reply ] |
|
Richard Goodwin |
Message #72668, posted by rich at 16:05, 12/12/2005, in reply to message #72662 |
Dictator for life
Posts: 6828
|
http://www.nist.gov/dads/terms.html
This any good for algorithm research? ________ Cheers, Rich.
|
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #72670, posted by Phlamethrower at 16:09, 12/12/2005, in reply to message #72668 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
http://www.nist.gov/dads/terms.html
This any good for algorithm research? Interesting
My todo list has now reached 10k in length, so I think it's about time I did some more coding |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #72674, posted by Phlamethrower at 19:37, 12/12/2005, in reply to message #72670 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
*adds support for sprites stored as raw data, then starts writing the nasty conversion program to convert to/from the format* |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #72675, posted by Phlamethrower at 20:02, 12/12/2005, in reply to message #72674 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
It works
The original sprite file for the test car is 111k. Converting it to the raw format brings it down to just 9k. Convert it back to a sprite file, and it's 46k.
However, that is when I save the sprites in delta form, as opposed to delta+base (as they are stored in the original file). Once I write the delta+base output it will be a bit larger (but not as big as the original sprites, since they had extra space around them).
And the 9k file loads instantly, unlike the 111k sprite file, which takes about a second to process (Load, convert to gnarlplot, calculate deltas, crop sprites, collect palettes). |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #72925, posted by Phlamethrower at 22:09, 24/12/2005, in reply to message #72675 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Well, I guess I'd better get some more work done then. |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #72932, posted by Phlamethrower at 01:36, 25/12/2005, in reply to message #72925 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Note to self: Add signal handlers/other stuff to prevent sound handler from trashing the computer when the code crashes SOON. |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #72962, posted by Phlamethrower at 01:08, 26/12/2005, in reply to message #72932 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
*curses preprocessor* |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #72977, posted by Phlamethrower at 14:51, 26/12/2005, in reply to message #72962 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
If I turn off the tile plotting funcs, the game runs at around 130-170 fps
Which means that about 95% of the time each frame is taken up by the C tile plotting funcs |
|
[ Log in to reply ] |
|
Phil Mellor |
Message #72978, posted by monkeyson2 at 15:17, 26/12/2005, in reply to message #72977 |
Please don't let them make me be a monkey butler
Posts: 12380
|
If I turn off the tile plotting funcs, the game runs at around 130-170 fps
Which means that about 95% of the time each frame is taken up by the C tile plotting funcs Could an Iyonix version use Simon's nVidia driver? |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #72979, posted by Phlamethrower at 15:42, 26/12/2005, in reply to message #72978 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Could an Iyonix version use Simon's nVidia driver? Yes.
There's still lots of optimisation for me to do though, e.g. those fixed width plotting funcs. At the moment I'm compiling a simple assembler version of one of the two plotting funcs, so it'll be interesting to see how much faster that makes it (Probably not a lot). |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #72980, posted by Phlamethrower at 16:12, 26/12/2005, in reply to message #72979 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
No difference in speed at all
Caching a division result doesn't change the speed either, so it looks like it's the pixel copying code that needs optimising. Which is where the fixed width plotting funcs will come in |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #72981, posted by Phlamethrower at 16:19, 26/12/2005, in reply to message #72980 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
And I can now confirm that LDRH and STRH don't work on the Risc PC |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #72982, posted by Phlamethrower at 16:50, 26/12/2005, in reply to message #72981 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
After tweaking the code a bit, the game now runs between 17 and 24 fps |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #72986, posted by Phlamethrower at 18:44, 26/12/2005, in reply to message #72982 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
*finally starts work on car shizzle* |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #73000, posted by Phlamethrower at 23:47, 26/12/2005, in reply to message #72986 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
*gives up trying to understand and write his own implementation of this and just copies the example code* |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #73002, posted by Phlamethrower at 00:48, 27/12/2005, in reply to message #73000 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
It appears that converting the code to fixed point math, angles in degrees, a different coordinate system, and a different scale isn't that easy |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #73005, posted by Phlamethrower at 02:27, 27/12/2005, in reply to message #73002 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Why won't this SWI return an error?!?! |
|
[ Log in to reply ] |
|
JMB |
Message #73006, posted by jmb at 03:23, 27/12/2005, in reply to message #73005 |
Member
Posts: 467
|
Why won't this SWI return an error?!?! Because it doesn't like you? Alternatively, it could quite probably be the SCSI system returning no error at all (the above SWI is just a thin veneer over the SCSI SEND_DIAGNOSTIC command). Equally, it's quite possible that the CDFSSoftATAPI implementation sucks. I'm pretty sure that the general consensus on that SWI (if not the entire CD access API) is that it's hideously broken - heck, there's a reason Acorn didn't document it in PRM 5a |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #73008, posted by Phlamethrower at 13:18, 27/12/2005, in reply to message #73006 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
The physics is kind of working now. Doesn't seem quite as good as the website suggested, though.
*goes to poke* |
|
[ Log in to reply ] |
|
Phil Mellor |
Message #73009, posted by monkeyson2 at 14:06, 27/12/2005, in reply to message #73008 |
Please don't let them make me be a monkey butler
Posts: 12380
|
The physics is kind of working now. Doesn't seem quite as good as the website suggested, though.
*goes to poke* |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #73010, posted by Phlamethrower at 15:02, 27/12/2005, in reply to message #73009 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
My code is better (In particular, it doesn't generate high lateral forces at low speeds, which will send the car into an unstoppable spin)
Still appear to be having some problems getting cornering working properly though. |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #73105, posted by Phlamethrower at 03:36, 31/12/2005, in reply to message #73010 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
*trips over thread*
Um, yes. Must do more work soon.
Actually, if I were to release a build+source+docs tomorrow (today), how many people would return the favour by promising to provide some code/graphics/sounds/designs?
(Hint: If the answer is zero, I won't bother releasing a copy )
Depending on what I get up to tomorrow, I may have a go at writing a new rotated/scaled sprite plotter. The current system projects the corners of the sprite onto the screen and then follows the left and right edges down from the top point. This leads to small inaccuracies on some sprites (e.g. wrapping sprite coordinates) and large inaccuracies on others (e.g. sprites being plotted with a ghost copy next to the main image). I've tried to tweak the algorithm in the past to improve accuracy, but often end up with unexpected divisions by zero.
Instead I'll go for a slower but 100% accurate stepping algorithm - starting from the sprite origin it will move up to the top of the sprite one pixel at a time, then search sideways to find the left and right edges of the scanline. It will then step down the edges of these lines, until it reaches the bottom of the sprite. Range checks on sprite coordinates will be performed at each step to make sure that the resulting lines are 100% within the sprite.
Considering that this algorithm won't use any divisions, it may be faster for smaller sprites. I can also rework the current screen bounds checking to fit in with the main algorithm. I might even be able to write it in assembler. Hmm.
#define INRANGE(sprx,spry,scrx,scry) (((sprx)>=0) && ((spry)>=0) && ((sprx)<(sprw >> 16)) && ((spry)<(sprh >> 16)) && ((scrx)>=0) && ((scry)>=0) && ((scrx)<scrw) && ((scry)<scrh))
// code snippet assumes following vars already set: // f1616 sprx,spyr - sprite coordinates of top left corner (as seen on screen) // int scrx,scry - screen coordinates of top left corner // int len - Line length, pixels // f1616 sprxd,spryd - sprite deltas per screen x (parameters supplied by caller) // int sprw,sprh,scrw,scrh - sprite, screen sizes
while (len > 0) { // (Insert call to the line plotter func here, can't remember name/syntax) // Go down a row scry++; sprx -= spryd; spry += sprxd; // Move left edge of line out while (INRANGE(sprx,spry,scrx,scry)) { scrx--; sprx -= sprxd; spry -= spryd; len++; } // Move right edge of line out while (INRANGE(sprx+(len-1)*sprxd,spry+(len-1)*spryd,scrx+(len-1),scry)) len++; // Move left edge back in while (!INRANGE(sprx,spry,scrx,scry) && (len > 0)) { scrx++; sprx += sprxd; spry += spryd; len--; } // Move right edge back in while (!INRANGE(sprx+(len-1)*scrxd,spry+(len-1)*spryd,scrx+(len-1),scry) && (len > 0)) len--; }
And, erm, that should do it! (Apart from the bit which finds the top left corner to start with). The INRANGE macro can be optimised a bit, in particular keeping note of the sprite coordinates for the right end of the line. The good news is that when converted to assembler I can just use unsigned comparisons to do the range checks (Of course there's nothing stopping me from doing them in C, either). The expanding-before-shrinking should ensure that len only ever reaches zero when the bottom of the sprite (or screen) is reached. Unfortunately, there probably won't be enough registers for the assembler version:
1. sprite pointer 2. screen pointer 3. sprite x 4. sprite y 5. screen x 6. screen y 7. line length 8. sprite x delta 9. sprite y delta 10. sprite width 11. sprite height 12. screen width 13. screen height 14. sprite x of line end 15. sprite y of line end 16. stack pointer 17. program counter
Hmpf
I can probably squeeze a couple of registers together. Of course 1-9 and 16-17 need to be supplied to the line drawer as-is, so that limits my options a bit. It may just be simpler to scrap 14 & 15, and calculate their values in one temp register instead.
Plus since the line plotting functions are meant to adhere to the APCS (in particular the plotter generators are written in C), I may need to rustle up another register to store the stack frame pointer in I could probably merge the screen dimensions into one register, but without writing a bit of code to check I'm not really sure (not that there's really much left to write as code now ) |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #73137, posted by Phlamethrower at 22:34, 31/12/2005, in reply to message #73105 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Actually, if I were to release a build+source+docs tomorrow (today), how many people would return the favour by promising to provide some code/graphics/sounds/designs?
(Hint: If the answer is zero, I won't bother releasing a copy ) I guess that'll be zero, then.
I may have a go at writing a new rotated/scaled sprite plotter. Done. I think it may be faster, too
Still need to do the assembler one, though. |
|
[ Log in to reply ] |
|
Richard Goodwin |
Message #73141, posted by rich at 22:53, 31/12/2005, in reply to message #73137 |
Dictator for life
Posts: 6828
|
Actually, if I were to release a build+source+docs tomorrow (today), how many people would return the favour by promising to provide some code/graphics/sounds/designs?
(Hint: If the answer is zero, I won't bother releasing a copy ) I guess that'll be zero, then. I'd love to volunteer, but I don't have enough time for the things I'm supposed to be doing now, never mind taking more on! ________ Cheers, Rich.
|
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #73142, posted by Phlamethrower at 23:07, 31/12/2005, in reply to message #73141 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Actually, if I were to release a build+source+docs tomorrow (today), how many people would return the favour by promising to provide some code/graphics/sounds/designs?
(Hint: If the answer is zero, I won't bother releasing a copy ) I guess that'll be zero, then. I'd love to volunteer, but I don't have enough time for the things I'm supposed to be doing now, never mind taking more on! It's OK, it means I don't have to bother writing any documentation yet
However if someone can obtain a good set of sound samples then it would be useful. A few days ago I tried searching for some free sounds and not many of them seemed usable (e.g. a clip of a siren that doesn't even run long enough for the siren to repeat once ) |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #73148, posted by Phlamethrower at 02:27, 1/1/2006, in reply to message #73142 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Anyone know a good way of writing a SharedSound buffer fill routine that won't trash sharedsound/the computer when the program it belongs to unexpectedly dies?
I've tried signal handlers in C, but either my code was wrong or they don't get called under all situations (I think I've had this problem before, when playing with multithreading). I've also tried calling Wimp_ReadSysInfo to get the active task handle from the inside the buffer fill code, but it doesn't look like the processor is always in the right state for that to work. (plus the buffer code had been copied to the RMA, to ensure it still exists after the program has died). I also tried adding an error flag (flag gets checked when buffer fill starts, disables handler if error had occured, else set error flag, run fill code, clear flag on exit), and although that did detect an error and disable the fill code, the error still managed to trash sharedsound (With the code held in the RMA again).
Now I'm thinking that I need to use OS_ChangeEnvironment to install my own error/exit/upcall handlers, and detect the errors occuring through them. However that involves writing various bits of code to remember the old handler data, pass on calls, disable the handlers when the buffer fill code is removed, etc.
Surely there's a simpler way?
I also considered moving all the sound sample data to a dynamic area (and buffer fill code to the RMA), so that even if the game crashes the sound fill code shouldn't. But that wouldn't work very well with the system I'm using to update sample positions, and I'd have to write my own memory manager, and after experimenting with Wimp_ReadSysInfo I still wouldn't have a way of detecting when the program has ended. Of course I could change the type of buffer fill code to a callback handler, which will presumably remove whatever problems I was having calling Wimp_ReadSysInfo. But that seems a bit lame considering that it doesn't need to be on a callback, and knowing SharedSound probably hasn't even been implemented.
Speaking of which, why isn't AMPlayer coexisting with DeathDawn's buffer fill code? Arg! |
|
[ Log in to reply ] |
|
Pages (22): |< <
8
> >|
|