Jump to content
IGNORED

Arghh! I QUIT!!


Heaven/TQA

Recommended Posts

rock on dude!

 

you will get a powerful feeling when you are watching your child grow. and as jet boot jack said... after it is finished you will be proud.

 

and not to forget. with every 6502 line you are getting more and more experienced. examples?

 

ok:

 

you know this

 

lda #0

sta blabla

ldx #0

lda blalbla2,x

 

better to do this

 

lda #0

txa

sta blabla

lda blabla2,x

 

or this classic

 

clc

lda a

adc #

sta b

lda a+1

adc #0

sta a+1

 

clc

lda a

adc #

sta a

bcc label

inc a+1

label ...

 

you will create a own style of coding... and 6502 is really a "risc" processor nowadays compared to pentium, motorolla, etc...

 

(ok R3000 in PSone rocks... this chip is back to the roots... ;=))

Link to comment
Share on other sites

After I get a couple 5200 games done, whenever that actually occurs, I think I would like to try out GBA development.

 

Hey, thanks for the replies guys. Last night was yet another frustrating night. Sometimes I think I can accomplish something in only an hour or two, then I work 3 hours and its only half done! I'm certainly not the fastest ASM coder in the west! But Heaven is correct, with every line I do get more familiar with 6502 coding and the methods used.

 

One thing that I have not done is try to estimate how many cycles I'm using up. I have several DLI's down the screen (6 I think), which cuts into the 6502's cycle time, correct? I'm going to keep adding code until I notice a problem (if ever) and then try to deal with it at that point -- I hope I don't have a problem, though!

 

My biggest hurdle has been trying to animate background graphics. I'm not trying anything fancy, either. I've been experimenting with trying to animate flames and in moving Pyro the cloud in my game; Pyro is made of '01' and '10' bits. To move a bg-graphics series of bytes to (for example) the right smoothly, you just don't move each byte to from $2100 over to $2101 -- that would in effect move each pixel 4 spaces over and is jerkier than one pixel at a time animation.

 

Also, in order to move BG graphics, I have to (1) read the data (bytes) from a table, storing it in a register, (2) store it in the new location in memory -- for even a 10X20 "character", thats 200 bytes! I suspect I can't do much of this without problems.

 

Anwyay here's a peek. It's very pixelated due to my shrinking it and turning the .bmp into a .gif (so that Angelfire will allow it to be linked), so don't mistake pixelation for 'detail'.

 

koffi_mv1.gif

 

Also, I've been using an animated gif package to mess around with ideas for 1-color fire effects. Here's one of the gifs:

 

koffi_fireidea6.gif

 

Later!

Link to comment
Share on other sites

Cafeman,

 

You said: "One thing that I have not done is try to estimate how many cycles I'm using up. I have several DLI's down the screen (6 I think), which cuts into the 6502's cycle time, correct? I'm going to keep adding code until I notice a problem (if ever) and then try to deal with it at that point -- I hope I don't have a problem, though!"

 

Antic does all the work on DLI's the 6502 is pretty free - don't worry about CPU time worry about ANTIC and the Vblank!!!!

 

And: "My biggest hurdle has been trying to animate background graphics. I'm not trying anything fancy, either. I've been experimenting with trying to animate flames and in moving Pyro the cloud in my game; Pyro is made of '01' and '10' bits. To move a bg-graphics series of bytes to (for example) the right smoothly, you just don't move each byte to from $2100 over to $2101 -- that would in effect move each pixel 4 spaces over and is jerkier than one pixel at a time animation."

 

If you are using character modes use multiple charactersets, and flip charbase to animate them!!!!! Its almost free of charge and looks GREAT!!! To move big graphics in character modes also use animated character sets to shift images thru characters smoothly...

 

And lastly: "Also, in order to move BG graphics, I have to (1) read the data (bytes) from a table, storing it in a register, (2) store it in the new location in memory -- for even a 10X20 "character", thats 200 bytes! I suspect I can't do much of this without problems."

 

Again bitmapped vs characetr modes - look at Donkey Kong - bitmapped mode, LOADS of moving objects - secret in the masking simply OR or AND the images to the background... I would still reccommend clever use of chacatersets and sprites as the BEST solution looking at the images of Koffi I see no reason why it couldn't be done in character modes.

 

sTeVE

Link to comment
Share on other sites

Antic does all the work on DLI's the 6502 is pretty free - don't worry about CPU time worry about ANTIC and the Vblank!!!!

 

===> What should I worry about? I think you mean that I have to have all my graphics (screen RAM) changes done before Vblank ends. Is this what you mean?

 

Again bitmapped vs character modes - look at Donkey Kong - bitmapped mode, LOADS of moving objects - secret in the masking simply OR or AND the images to the background... I would still reccommend clever use of chacatersets and sprites as the BEST solution looking at the images of Koffi I see no reason why it couldn't be done in character modes.

 

===> What Antic mode does 8bit DK use then?

 

You know, I started programming Koffi using Antic E, and I'm staying with Antic E for now. I have wondered if Koffi should have been in character map mode, perhaps I started down the wrong path? Well, I'm going to see how well I can do it in Antic E since I'm so far along. I picked E because my favorite games such as Defender and Joust used Antic E, so I figured why not?

 

The other game I'm working on, Adventure II, is in character mode. By the time Alan and I are done with Adv II, I'll have a better grasp of when to use character vs bitmapped modes.

 

One thing I realize now is that Antic 4 Character mode allows 5-colors per character; with Antic E you get 3 colors + background, changeable only via a DLI. So I probably could program Koffi using character mode visuals. But I do not know how to accomplish the missile-command effect of the lighting 'streaking' pixel-by-pixel across the bg, if I were to try Antic 4. It seems like I'd need a lot of characters to animate certain dynamic things like that.

Link to comment
Share on other sites

re: animated background

 

easiest way to keep the frame rate stable is to use 4-8 charsets a 1024 k... less than your antic e screen...and amount of bytes to update in screenram is max. approx. 960 bytes (40x24) instead if 7680.

 

just change the animated chars in every charset. check out "zepelin" or "schloss schreckenstein" on atari 8bit...as examples

 

defender in antic e... sorry to say that looks crap... check out instead "dropzone"

which works in charmode BUT has smooth grafics by my lovely Archer McLean who has done the brilliant "International Karate" (in the states called "world championchip karate"). even IK uses Charsets! not hires like in Karateka.

 

Joust is my Fave but looks good because the Jousts are PlayerMissles. I love the PM-Engine doing a lot of PMs. Has anybody tried something similar to do? you know if more than 4 PMs at 1 scanline then start flickering...

 

jet boot jack:

 

PS2: you are right. when using the Vector Engines 1+2 in PS2 you can make a lot of things... ;=)

 

Xbox: is it really similar to PC? except the Memory seperation? i guess a direct port with new Visual Studio should be possible...(Compile to Xbox... ;=))

Link to comment
Share on other sites

Sorry I didn't code DK, but is is in Antic E...

 

Joust and Defender on the other hand both use an Antic 4 display...

 

Cafeman - I was refering to the DLI management not using any (or few) CPU cycles. You should be able to do a DLI, changing a characterset every modeline, or alter 3 color registers ever mode 7 line. Really tight code, doing no user input or little AI could change 3 color registers every Antic E line - Fun with Art managed it.

 

X-box - PC like - well yes it is, but its a good bit o hardware, at an incedibly cheap price ($299). Its very easy to code for, the unified memory and HD makes a world of difference compared to PS2.

 

sTeVE

Link to comment
Share on other sites

Well there you go - I assumed these games were done in character mode - no need to be in bitmapped modes - Joust especially (unless the vultures are not all done with players) - my assumption.

 

Id the DL all mode E lines - or does it start mode E and then change modes - simply to declare enuff RAM?

 

What is done in Joust with Bitmapped FX?

 

Defender looks like it could be either way - no compelling reason for it to be bitmapped - I guess looking at Stargate its logical to be bitmapped - same code base I guess..

 

sTeVE

 

[ 12-10-2001: Message edited by: Jet Boot Jack ]

Link to comment
Share on other sites

I have to disagree about Defender, only because I've spoken to the author, Steve Baker about it. He in fact told me to arrange the data as vertical strips then insert logic as to when to display each -- sounds like Sprite DLI reuse to me.

 

I was always pleased and impressed with Baker's job on Defender -- the game looked and played GREAT. It much better overall than the Colecovision one, for example, a system which on-paper should have had the superior port with its more sprites available. But I don't want to fight over it!

 

By the way, do you (or anyone) know who programmed Atari 8bit and 5200 joust? I've always wondered, never found out though.

Link to comment
Share on other sites

cafeman:

 

sorry...i disagree with you conc. defender...

 

on my pal machine it flickers because of the damned software sprite engine used...stargate was much better at this point...i have never seen an atari 800 game which uses software sprites and worked in 50/60 frames per second...

 

and again... please double check it with dropzone (great defender clone...)

http://www.retroplayers.com/consolemuseum/...itdropzone.html

 

atari's video hardware was not born for software-sprites... ;=)

 

so i still prefer not to use Antic E. btw. joust used it because easier to handle the sprite multiplexer maybe because of setting the dli bit and calculating is easier...

 

ok...the egg movement is nice but... if you have ever coded a software sprite engine then you know that it is not so easy with collision detection...

 

as the birds are Player/missles (even the lava troll) you can easily have the eggs precalculated in memory (remember...16 K max! - 8k for antic E...no space for double buffering...) for every pixel position...

 

but if you have "real" action game with lots of sprites... well... you have to store the precalculated shapes, the masks of the sprites... maybe a collision mask... because "ASL" + "ROL" the whole things does not improve your ingame speed... ;=)

Link to comment
Share on other sites

Yes, I've noticed the 'flicker' but I had seen far worse on 2600 so it never really bothered me, nor did I initially even notice it.

 

So you are saying that the 'flicker' is because Baker used software sprites. In other words, background graphics. Strange, the collision seems to be flawless. When you mention a 'collision mask', i don't know how one would go about implementing that. I'd have to see an example to understand, I think. I just use the 5200's collision registers so far -- I've managed to get by since all the '11' bits are deadly to the helicopter, and the '01' and '10' bits simply cause him to bounce off them.

 

Way back last summer of 2001, I asked a question about Antic E and other modes -- what are the advantages, etc. You both seem to think Antic E is a mode never to be actually used then?

Link to comment
Share on other sites

I'm not saying ANTIC E is not a great mode - it is, and the 8bit can shift software sprirtes with the best of them (far better than the C64 could manage).

 

But unless there is a compelling reason to use this high RAM mode I'd say that the character modes really give you the best tradeoff (All the games I've ever done on the XE including Shadow of the Beast and Last Ninja II used Antic 4).

 

As for the software sprite kernal Baker describes - its nothing like a DLI - 'cos the 6502 is doing all the work!!! The beauty of the 8bit architecture is the independence of ANTIC and the 6502, not slaving the 6502 to the screen draw allows such possibilities. However you can use the 6502 to do everything if you really want

 

With the spare 6502 time you can always use it to do complex character color kernals, or spiffy audio etc

 

Vertical sprite re-use with DLI's is the "cheapest" way to get loads of independent objects running around - almost the only way you're gonna get 60fps!

 

sTeVE

 

[ 12-11-2001: Message edited by: Jet Boot Jack ]

Link to comment
Share on other sites

ola steve!

 

i am highly interested in getting demos or working betas of atari versions of shadow of the beast and last ninja 2.

 

how did you managed them compared to c64 versions? f.e. no big sprites and charmode 512 characters compared to 128 on atari?

 

i think this restrictions make it not so easy to convert shadows of the beast or better the highly grafic usage of the last ninja 2...

Link to comment
Share on other sites

Beast - we did that in Antic4 - for the exterior areas we used 2 character sets - sky, and foreground - all enemies were sprite based.

 

Interiors we used one character set per area, with 4 versions for animation. The enemies were a mix of characeter and sprite objects. We split the screen into 4 areas and scrolled them independently when needed for large enemies or groups of enemies.

 

Last Ninja - once again many character sets - so each screen had the same detail as the C64 version. The sprites were simple - 16 pixel wide monochrome - he's just a black ninja after all! the priority masking was handled just as the C64 version - loads of character data shaped masks in ram that get overlaid into the sprite data with a boolean (AND I think) to create the illusion he's going behind objects....

 

The data will be available soon - I'm moving to San Jose in Jan - so I can unpack then!!

 

sTeVE

Link to comment
Share on other sites

We used DLIs to put multiple character sets on screen and vertically alter color palettes. Any one line only has 5 character colours, but each mode line can have a couple of those colors changed...

 

Also for some areas we used enlarged PMG masked by characters to create other color zones.

 

sTeVE

Link to comment
Share on other sites

I redrew the LN2 art based on the C64/ST data, in OCP...

 

Beast I used OCP on the ST to mash the Amiga graphics to 160 pixel screens, then ripped that into 8X8 elemnents which were heavily reworked then squirted it all down to the XE and reworked/retouched in a character editor.

 

The other titles (Pacland, Menace for instance) I did all original intpretations from the Arcade/Amiga.

 

sTeVE

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...