Sheddy

Goochman, I'll be honest - I don't like the look of either of the green colours for Uriah, but now its been pointed out I do see what you're talking about. Maybe changing the man's colours would look better? (although it won't match the colours of the man when he's on the other stages so well) What do other people think about the colour schemes?

That's it exactly. Just DLIS changing the background colour. There's a very simple 3 frame loop animation on their positions to give the impression of forward movement and then the colours swap over to continue the illusion of movement - just like a disco light rope/chaser lights.......Hmm....That explanation sounds more complicated than it really is: Imagine something going from right to left instead, 000 and ||| are the colours: 000|||000|||000 00|||000|||000| 0|||000|||000|| ....swap colours |||000|||000||| ||000|||000|||0 |000|||000|||00 ....swap colours again 000|||000|||000 ....just keep on going!....

you mean the blue pants of the man and the blue of uriah? suppose it could be made into a green from the palette (either of the greens on the plant thing in the shot below), but I see the bluey tint as a better fit to the original. On the cart version I'm hoping for 16 frames per second instead of the 12 frames a second at present on this bonus stage, which should give a similar impression of speed as the original. (The rest of the game is running at 16 frames per second at the moment anyway)

Cool! Are you intending to offer larger cards at some point?

looking good - backup plan or not!

I think you could better use PM 3/4 for filtering colors, because this allows for a partial shine-through. Playfield Color 0 & 1 clip PM color 2 & 3, so they are only usable as large solid blocks. Waaah! i have this worked out and running but nobody'll answer a simple question here!! =-( In a nutshell - I don't think you can do exactly what you want - which is why I think they're leading you round the houses! - the overlap function is either on or off, and can't be applied to individual players. Check out http://www.atariarchives.org/mapping/memorymap.php mem locs 623 and 53275 for the [sarcasm] "vast array of" [/sarcasm] overlap/priority options you have at your disposal

Sorry - double post

so, this time actually answering your question ......$70,$70,$30 would do it BTW My brother started having a go at converting Bubble Bobble for the atari, before he moved over to the "dark side" - Amiga (his demo handle was "The Bunge"). Unfortunately, after touching the Amiga, he never went back to finish it. He had a cool map editor, that automatically did the drop shadows on the level layouts - but then he was always a clever sod! Actually I love the Amiga (thank you Mr Miner et al) 'coz it's so similar to the atari in many ways. Just hate the skinny sprites (same problem as atari)

How do i balance that out in the display list, do i need $70,$70,$70 at the top or can i use $70,$70,$30 to centre a 200 line display...? Most of the CPC action games i've seen are quite slow, i think CPC Turrican is dropping three to four frames per refresh and i'd consider that unacceptable. Hardware-based vertical and fast (8 pixels a frame) horizontal scrolling are both possible on the CPC by messing with the CTRC, by allowing for the repositioning of the screen in the software sprite routine and writing over the data that's just wrapped around it's theoretically possible to hammer a full screen full framerate scroll with the majority of the CPU power available for the sprites. Oh, for reference the Z80 used in the Amstrad requires close to twice as many cycles a command as the 6510 in the C64, meaning it's only about twice the speed in real terms and the Atari's 6502 should therefore be damned close to matching it. It's OK to leave the normal blank line stuff in the top of display list, as the PAL or NTSC hardware compensates so both will appear centred using the same display list. The 16K bitmap amstrad screen is just a little too big for an 8-bit to really handle comfortably, although I would have loved for such a mode available on the atari or the c64 (think of the DMA cycle stealing/bad lines though!)

I can't see how character mode could be made to work very fast for a game like mine (with smooth vertical movement, and masking overlaps) ??? Whatever arrangement of characters I can think of makes it slower to draw to than a bitmap - but I'd love you to prove me wrong Also don't foget you do still need to clear areas of memory in the character definitions themselves if you're treating them more like a bitmap (but not the whole lot necessarily) - negating some of the speed advantages

I figured "cld" at startup meant all numbers were BCD Your suggestions worked but it just wont roll from 1 to 0 but straight to 9 and 11 to 10 is messed up btw it doesn't do all 6 numbers just the first one and if it's changed it checks the next one. also it's not a "real" score display so this should work just fine The CLD won't make a difference to INC or DEC. Only the maths instructions are affected (ADC and SBC). Don't ask me why, but INC and DEC don't count as maths.....well they do COUNT......but you know what I mean Assuming you are NOT working in decimal, you also don't need the "lda score,x" - the DEC will also flag for zero or negative. And just change the "lda #10" to "lda #9" as Manuel suggests, and you should be in business (I think!)

Dare I say it......but.... overlaid expanded players could work quite well on the tiles on the right (combined with usual char graphics)???

OK, here's the fixed up version - with a little extra at the end too. Enjoy uriah.zip

You're always very observant emkay There is no good reason why the PAL version is running slower. I had taken the PAL compensation code out to see if I really needed it (and I do!) On NTSC Uriah, the screen is changing every 5 VBI's = 60/5 = 12 frames per second. Without an adjustment for PAL this goes down to 50/5 = 10 frames per second. With the adjustment code left in it would change every 4 VBI's when PAL is detected - giving a slightly faster speed of 50/4 = 12.5 frames per second. In fact I'm going to redo the demo now - I should really have fixed it even though it's only a very rough demo - literally a snapshot of the working code on the day.

Strange... works fine on 3.1 too (and the real thing) The PAL music is too slow and the dragon is also too slow. Suppose I ought to fix it for PAL really! The shooting demo does run at the correct frame speed though, except for the PAL music again. I can't think of a way to do a 32K cart (ie 5200) - the way things are now, it might just squeeze into a 512K cart and need at least 48K RAM! But I want to try a 2MB cart for some graphics speed improvements which may or may not come off. Concerning other comments, especially about flicker - cheques in the post!

Why don't I just put the file here... uriah.zip

Thanks for the compliments guys! Please feel free to be a bit harsh where you think things are lacking though, and I'll see what I can do. (The dim colour palette I think I'm stuck with). Even though I try to, I've got too close to this thing to be able to stand back and see things objectively. I like how Dennis has really honed his "Climber" game based on the feedback he's got. My goal is to make things as close as possible to the original. Framerate will be a problem, especially on the later stages. I don't think I can make it go as fast as the original. It will only get a little faster than the first stage. This should be less of a problem with the cart version which I'm moving over to developing now.

Agreed. Turbocharge is a much better psuedo 3d game than Space Harrier The design of Robin Levy's graphics is very cleverly done, to try and make up for the lack of masking where things have to overlap. Given the tight release schedule from Elite (I believe they had less than 6 months to produce the game), it is not surprising Chris didn't get to perfect the graphics on Space Harrier in a similar way. His (understandable) fetish for single loader games at the time wouldn't have done it any favours either. I really wish they didn't have to have rushed it so - the C64 version could have been pretty good, instead of very average. (Still it looks better than the Amstrad version, which doesn't even have filled sprites, but vector representations) Guess they wouldn't have been able to dip into their toolbox of routines used on previous games either, to speed up development - as you say, it was pretty new territory.

Oh no. My worst nightmare! - you will notice quite a few differences. The Saturn version is totally *Perfect* In fact, I'm pretty sure all the games on Sega Ages are emulated rather than just ported. Interested you're using flickering on Adventure II. Makes it more authentic too, of course

Dennis, you have your PC screen refresh set to 60Hz? And the vertical sync option on the emulator? Cafeman's right that the flicker is less bad on the real thing (unless you're using a slow LCD monitor like me ) I found the external "real" palette to be closest (at least to my TV)

Hi Cafeman, I think you discovered a "feature" of Atari800Win! I've had something similar happen with some other things. XL/XE mode with 128K or above should work. Try "attaching" a different disk, then go back and attach again to drive 1. You will probably need the XL rom too, as oesii suggests. Tempest, yes, it is a limitation of the palette - disappointing I know, but flicker starts to get out of hand when the brightness is cranked up on the palette. You normally have your screen/monitor set at fairly low brightness? - Turn it up till the colours show up better, right up, to see what I mean about the flicker! Either I must have my TV set really bright to start with, or I've just got used to the muted colour scheme after all this time of working with it!

Hmm... OK, so mabe you can get similar results to something like Mood... :wink: BTW When I said "Vector" - I meant "Numen" - "Vector" was going to be the game based on the 3d Engine of Fox's which is also used in "Numen". My bad.

Mood's pretty impresive all right. Is there a reason why the Atari couldn't do something similar, TMR? Vector is based on a 80*48 screen from what I've read on Fox's site about it (sadly the site is no more). Without the real 3d of Vector, such an engine could presumably be done at a similar (if not faster) frame rate - not that Mood is in any way slow, it's very playable, considering what it's doing :wink: When I'm done with my current stuff, I'm really tempted to look at some of the clever methods used to create this kind of game. Don't hold your breath though, as I'm not particularly mathematically inclined or talented. Maybe emkay's ideas are slightly "pie in the sky" for this kind of game (Heaven's right emkay, we'd need a demo to prove the concept of the ideas!), but it's amazing what has been done already on C64.

Finally, more or less finished the dragon riding bonus stage, I hope There's a demo of it at the usual place www.sheddyshack.co.uk Do you think it's close enough to the original? (forget the scenery objects used on the demo, they will be changed in the final game). Does it need some changes?

Nice work on SB, Mark - looks very authentic. Hope you manage to find the time to carry on with it (after Elite, of course )