RE: ROM disassembly
On Wed, 8 Jan 2003 21:05:50 - "Simon Owen" <[EMAIL PROTECTED]> wrote: > Earlier I wrote: > > Simon Goodwin is still in touch with Andy Wright, so it might > > be worth checking with him. Actually, I found it on an _old_ floppy in WP 5.1 for DOS format (I think). Need to find a way to convert it and I'll upload it. However, it's for v3.0. It would be nice with a similar document for v3.1 (is it still the last one?). > Speaking of Simon, Andy and the SAM ROM... > > I've uploaded an archive containing 13 versions of the SAM ROM to incoming > on NVG. Simon sent them to me a while back, with permission from Andy to > make them freely available. I left out the version 1.1 ROM as it doesn't > appear to be in the correct format, but will upload a good copy if I can > find one. > > The ROMs aren't really of very much practical use, but still worth > preserving as part of SAM's history :-) Nice. Moved into sam/emuation/ROMs. -Frode -- ^ Frode Tennebø | email: [EMAIL PROTECTED] ^ | Ericsson AS.| Isebakkeveien 49 | | N-1788 Halden | Phone: +47 67 25 09 39 | | with Standard.Disclaimer; use Standard.Disclaimer; |
Re: ROM disassembly
On Wed, 8 Jan 2003 13:14:13 -0800 "Simon Cooke" <[EMAIL PROTECTED]> wrote: > That's a point; is the ROM source code up online anywhere? And if not, would > Andy mind it going up? I believe I've got an ASCII copy somewhere. It's in sam/sources on nvg. -Frode -- ^ Frode Tennebø | email: [EMAIL PROTECTED] ^ | Ericsson AS.| Isebakkeveien 49 | | N-1788 Halden | Phone: +47 67 25 09 39 | | with Standard.Disclaimer; use Standard.Disclaimer; |
RE: ROM disassembly
Frode Tenneboe wrote: > Actually, I found it on an _old_ floppy in WP 5.1 for DOS > format (I think). Need to find a way to convert it and I'll upload it. MS Word should still open/convert old WP files - if you've not managed it yet, e-mail it to me I'll have a go. Si
Scrolling (was RE: So long 2002, here comes 2003....)
John Gresham wrote: > I think scrolling has been done in a mode 4 game on the SAM. > Defender has a scrolling landscape and looks to be mode 4. I > think it sometimes shifts the land at pixel-by-pixel > resolution when you move slowly. The most you can move (using traditional "shift every byte" methods) in a single frame is about 1/4 of the screen (IIRC). Given that you need to move stuff around aswell, you'd probably only be able to scroll 2/3rds of the screen about every 15 frames (which should still be reasonably acceptable). Think of something like Blood Money or Wings Of Death, both for the Atari ST, where the screen moves quite slowly but the gameplay is still acceptable. > It looks like it's sometimes 2/3rds of the screen at times, > so I imagine Mode 4 scrolling can't be that slow??? Well things like Defender (I haven't seen the Sam version, but my memory of the game is of large blocks of single colour) cheat by only moving the edges. A bit like the old "Snake" game you get now on Nokia phones - since the mid-sections aren't moving you only need to draw the beginning and the end. My Big Scrolly Demo (on NVG, I believe) used this technique to draw a full-screen-height scrolltext. Cookie once showed me a demo of a neat routine that used screen switching to do 50fps parallax scrolling - very cool, since then all you need to do is draw the thing at the start of the level. Geoff This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com
Re: Scrolling (was RE: So long 2002, here comes 2003....)
>From Geoff: > Well things like Defender (I haven't seen the Sam version, but my > memory of the game is of large blocks of single colour) cheat by > only moving the edges. A bit like the old "Snake" game you get > now on Nokia phones - since the mid-sections aren't moving you > only need to draw the beginning and the end. > > My Big Scrolly Demo (on NVG, I believe) used this technique to > draw a full-screen-height scrolltext. Damn! This beats my 80 pixel high 50pfs scroller by 192-80 pixels! You can save some time per frame by turning off the screen and reducing screen contention, which looks... interesting. If you try turning the screen off for frames where the scroller/game has not updated, you get a dead smooth effect, unfortunately the brightness goes right down. Maybe it would be good for a ghost adventure? Middle of the night? Partial Blindness Survival-em-up??? -Tob
Re: So long 2002, here comes 2003....
>From Stuart Brady: > Then a new version of Elite for the Sam would be really good, as > I'm sure that the framerate, resolution, colour, and/or > sound/music and maybe even a few other things could be improved. > > I've heard that the BBC version works using a z-buffer, in thin > strips (due to memory contraints). The SAM can of course use much > larger > strips, but I'd like to know if there's any alternative to a > z-buffer. I've noticed that most of the time there are only one > or two ships visable on the screen at a time, so I'd have thought > that hidden > surface removal would often suffice. Any thoughts? Z buffering doesn't *seem* to provide enough saving for small amounts of objects to be useful. Obviously there are cases when one object obscures large amounts of another, but with a few objects this case is quite rare, relatively speaking. In the times when there ISN'T this case, z buffering takes up quite a bit of time. However it looks like hardware support for Z buffering will take off, cos these days there are always millions of polys on screen at once. Then the chances of obfuscation are pretty good, so the gamble pays off. (Just imagine I'm an old man who can't stand clever graphics. I like those games where you press a key to fire your weapons, and a message comes up - you have missed the target. **Press a key to fire your weapons**) -Tob
OT: Z-buffering was Re: So long 2002, here comes 2003....
> However it looks like hardware support for Z buffering will take > off, cos these days there are always millions of polys on screen at > once. Then the chances of obfuscation are pretty good, so the > gamble pays off. Just like PowerVR's gfx chips with tile rendering, which process the z-buffering for the screen in small blocks and render only what is visible. > (Just imagine I'm an old man who can't stand clever graphics. I > like those games where you press a key to fire your weapons, and a > message comes up - you have missed the target. **Press a key to > fire your weapons**) Have you seen the ASCII 'Pong' then online? Click to move bat up Click to move bat down ... you missed the ball. 0-1 to your opponent Colin Quazar : Hardware, Software, Spares and Repairs for the Sam Website: http://www.quazar.clara.net/sam/ Issue Three of "Sam Revival" Magazine Out Now !
RE: Scrolling (was RE: So long 2002, here comes 2003....)
Tobermory wrote: > Damn! This beats my 80 pixel high 50pfs scroller by 192-80 pixels! *chuckles* Cookie (again, damn him) took a different approach and used the border-scroll technique across the whole screen to build a scrolltext which filled the whole display. > If you try turning the screen off for frames where the > scroller/game has not updated, you get a dead smooth effect, > unfortunately the brightness goes right down. Maybe it would I can imagine that would look horrible on a decent monitor, though :( Geoff This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com
RE: Scrolling (was RE: So long 2002, here comes 2003....)
>From Geoff: > I can imagine that would look horrible on a decent monitor, > though :( SAM resolution? Decent monitor! Never the twain!
Re: OT: Z-buffering was Re: So long 2002, here comes 2003....
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit >From Colin: >> However it looks like hardware support for Z buffering will take >> off, cos these days there are always millions of polys on screen >> at once. Then the chances of obfuscation are pretty good, so >> the >> gamble pays off. > > Just like PowerVR's gfx chips with tile rendering, which process > the z-buffering for the screen in small blocks and render only > what is visible. Where was I? Suggestions - a good old depth sort from overall distance from the camera works quite well for space 3D. If you store a table of square roots for the Pythagoras, it speeds up nicely (big table, but hell, you'll already be storing perspective correction tables and SINE tables, so you won't be bothered about memory). You could also try doing a view frustum cull beforehand to reduce the list to just visible objects, or take the easy route and just make sure the objects are forward of the camera. You count the T-States and take your choice! Right now I'm tinkering with adding 'building block' sector coords to each object, like a vague grid reference. Then you could easily apply a 'bitmapped' view frustum to search the main area for potentially visible objects. I'm not convinced yet, but it may work -Tob
