Sheddy

August 9, 2003

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.

:idea:

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?

August 8, 2003

That scrolling ground / color cycling effect -- it is used in lots of forward scrolling classic games.

How do you pull that off, Sheddy? Do you use DLI's and change the bg color on each?

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

August 8, 2003

My $0.02 -

Forget about the dim colors, how about the color choice in general - The Dragon and Player are almost indistinguishable(On AtariWin 3.1 emu) - Could the Dragon be a dark green vs the dark gray it is now?

Otherwise it looks and plays well - Maybe a tad slow but if everything else is compensated then I think you can achieve a good overall feel.

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)

August 7, 2003

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

August 7, 2003

looking good - backup plan or not!

August 7, 2003

i'm not doing it that way, all i need to do is get players 1 and 2 filtering colours and players 3 and 4 as solid overlays - is this possible?

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

August 7, 2003

Sorry - double post

August 6, 2003

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

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)

August 6, 2003

And although PAL ATARIs can display up to 240 lines , it´s not recommended to use more than 200 , otherwise such games coul become unplayable on an NTSC machine.

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

And there are computers with no sprites/scrolling at all - Amstrad CPC for examples - that have fast action games.The Amstrad for example is a ca. 4Mhz Z80 machine , but uses a 16K 160*200 16 color screen AFAIK (or 4 colors in 320*200) and this means twice as much as the XL (so it loses the advantage of the twice-as-fat CPU) .But Turrican , Silkworm and other fast action games are available !

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

August 5, 2003

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

August 5, 2003

Hi there!
;decrease score
; Not working past 0

ldx #5

scloop2  

dec score,x  	; decrease score

lda score,x

cmp #0    ; is it 0

bne scdone2  	; no? then move on

lda #10    ; yes? then make it 10

sta score,x

dex    	; and the next number is 

beq scloop2  	; decreased ?

scdone2
Ok. The main bug is that you do "beq scloop2", ie "Branch if Equal". In this case an implicit compare with 0 happens, so it'd branch if X would be zero.

You should replace it with "bpl scloop2", ie "Branch if Positive". Then it is running from 5 to 0 as intended (As I assume )

Next thing is, you don't need to do "cmp #0" after a load. This is done implicit again, so you can remove that for being redundant.

And you probably want to switch from 0 to 9 rather than 1 to 10.

Finally, I hope you're aware that you're decreasing all 6 digits at once with this. For a real score display you'd better switch to BCD and 3 byte storage, as with 6 bytes in binary you'll most likely kill yourself programmig that...

HTH

Greetings,

Manuel
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!)

August 4, 2003

Dare I say it......but....

overlaid expanded players could work quite well on the tiles on the right (combined with usual char graphics)???

August 4, 2003

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

uriah.zip

August 4, 2003

Sheddy

Why is the URIAH-Level only fast on 60Hz? At 50Hz the cpu has more cycles available(please correct me if I am wrong).... Is there something depending on the VSYNC (VBI)?

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.

August 4, 2003

Yes! I finally got it to work. FYI, it only worked for me in Atari800Win 2.7, not in the newer AtariWin 3.0. Don't know why. My settings on both were 128K 130XE emulation. It worked on both PAL and NTSC -- I assume it should be PAL?

Color me impressed! The combination of the coin-op's music and the very faithful gameplay gave me a big smile. I'd really like to try out a shooting stage and see how that works. Concerning any flicker, I couldn't really see any, it is that minor. This game would never fit ona 32K cart, would it?

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!

August 3, 2003

:sleep:

:idea:

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

uriah.zip

August 2, 2003

I just played the arcade version on Mame, and your first level matches up quite nicely. To me this game is all about framerate, if you can keep a good fps than it should be fun to play, I've heard of other ports that didn't do this well. I also didn't play this one back in the day but I like the nice little touches in your 8bit port like the dying yelp

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. :sad: This should be less of a problem with the cart version which I'm moving over to developing now.

August 2, 2003

For pseudo 3D like Space Harrier uses, the advantages are reduced because the C64 can resort to lobbing large gobs of coloured data around at a reasonable rate of knots and it gets the advantage of the larger hardware sprites on top of that. Look at the later work of Chris Butler, when he wrote C64 Space Harrier it was pretty much the first of it's kind (Encounter covered the idea of large char based objects at speed but Harrier had more detail) and as he honed what he was doing the results improved until his final game, Turbocharge for System 3, blitzed Harrier for look and speed (having Robin "Armalyte" Levy on the graphics helped... =-)

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.

August 1, 2003

Thanks for the ROM and suggestions, I'll try it again tonight.

I have played a LOT of Space Harrier in my lifetime, in fact right now I have the Sega Ages disc in my Saturn (Outrun, Space Harrier, and Afterburner II) and I've played Space Harrier every night this week. I can't wait to comment on the differences/similarities!

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

August 1, 2003

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)

August 1, 2003

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!

August 1, 2003

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.

August 1, 2003

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.

August 1, 2003

Finally, more or less finished the dragon riding bonus stage, I hope :roll:

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?