Forums

Username:

Password:

User accounts

Register new account
Forgot password

Forum stats

List of members

Search the forums


Advanced search

Recent discussions

- RISC OS 'Advent' Calendar 2024 - David Pitt (News:)
- Elsear brings super-fast Networking to Risc PC/A7000/A7000+ (News:)
- November 2024 News Summary (News:1)
- Latest hardware upgrade from RISCOSbits (News:)
- WROCC November 2024 talk o...ay - Andrew Rawnsley (ROD) (News:3)
- Accessing old floppy disks (Gen:3)
- November developer 'fireside' chat on saturday night (News:)
- RISCOSbits releases a new laptop solution (News:4)
- Announcing the TIB 2024 Advent Calendar (News:2)
- RISC OS London Show Report 2024 (News:1)

Latest postings RSS Feeds

RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
 
View on Mastodon
@www.iconbar.com@rss-parrot.net

Site Search

 
Article archives
The Icon Bar: The Playpen: Slightly cold news on page 10! Phlamey breaks the server.
 
  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
PhlamethrowerHot 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
PhlamethrowerHot 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
PhlamethrowerHot 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
PhlamethrowerHot 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
Rich
Dictator for life
Posts: 6828
http://www.nist.gov/dads/terms.html

This any good for algorithm research?
________
RichGCheers,
Rich.
  ^[ Log in to reply ]
 
Jeffrey Lee Message #72670, posted by Phlamethrower at 16:09, 12/12/2005, in reply to message #72668
PhlamethrowerHot 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 :o

My todo list has now reached 10k in length, so I think it's about time I did some more coding :P
  ^[ Log in to reply ]
 
Jeffrey Lee Message #72674, posted by Phlamethrower at 19:37, 12/12/2005, in reply to message #72670
PhlamethrowerHot 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
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15100
It works :E

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
PhlamethrowerHot 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
PhlamethrowerHot 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
PhlamethrowerHot 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
PhlamethrowerHot 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
monkeyson2Please 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
PhlamethrowerHot 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
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15100
No difference in speed at all :P

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
PhlamethrowerHot 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
PhlamethrowerHot 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
PhlamethrowerHot 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
PhlamethrowerHot 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
PhlamethrowerHot 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 :P
  ^[ Log in to reply ]
 
Jeffrey Lee Message #73005, posted by Phlamethrower at 02:27, 27/12/2005, in reply to message #73002
PhlamethrowerHot 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? :P
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 :P
  ^[ Log in to reply ]
 
Jeffrey Lee Message #73008, posted by Phlamethrower at 13:18, 27/12/2005, in reply to message #73006
PhlamethrowerHot 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
monkeyson2Please 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*
:drool:
  ^[ Log in to reply ]
 
Jeffrey Lee Message #73010, posted by Phlamethrower at 15:02, 27/12/2005, in reply to message #73009
PhlamethrowerHot 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
PhlamethrowerHot 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? :o

(Hint: If the answer is zero, I won't bother releasing a copy :P)

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 :P

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 :P 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 :P)
  ^[ Log in to reply ]
 
Jeffrey Lee Message #73137, posted by Phlamethrower at 22:34, 31/12/2005, in reply to message #73105
PhlamethrowerHot 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? :o

(Hint: If the answer is zero, I won't bother releasing a copy :P)
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 :o

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
Rich
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? :o

(Hint: If the answer is zero, I won't bother releasing a copy :P)
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!
________
RichGCheers,
Rich.
  ^[ Log in to reply ]
 
Jeffrey Lee Message #73142, posted by Phlamethrower at 23:07, 31/12/2005, in reply to message #73141
PhlamethrowerHot 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? :o

(Hint: If the answer is zero, I won't bother releasing a copy :P)
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
PhlamethrowerHot 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? :o

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 > >|

The Icon Bar: The Playpen: Slightly cold news on page 10! Phlamey breaks the server.

© Copyright One Point Nought 2000 - 2024.About | Staff | Contact us | Privacy policy