Concepting a Conversion #1: Fire One

[Cybergoth]

Hi there!

 

Here's a black background one... it is rather hard to see.

 

Thanks!

 

Greetings,

Manuel

[Tom]

hello. i've been busy a bit with other stuff lately (among other things i built an f6 eprom cart / eprom simulator adapter for the 2600, learnt 7800 coding and created rfk7800).

 

anyway, here's some first damage bar code.

i didn't do it with a sixchar kernel, i found a different way (not necessarily a better one, though):

 

the background is used to draw the red part of the damage bar. P0 and P1 (quad sized) form the green part of the bar and are moved to the left the more the ship is damaged, thus revealing the red background.

 

a reflected black playfield with priority over the players is used to mask out the players as they move to the left out of the damage bar.

 

this approach needs quite some cpu time to set things up (two objects need to be positioned), and perhaps we might be better off with a conventional sixchar kernel. this way the player setup also needs to be done only once where the damage bar is over the torpedo display.

 

but there are two nice things about this method:

- while the bar is actually being drawn, the cpu is totally free for other things.

- the bar can be up to 64 pixels wide.

dmgbar2.zip

[Tom]

ah yes...the yellow area above the bar shows the amount of time needed to set up everything for the bar.

[Cybergoth]

Hi there!

 

ah yes...the yellow area above the bar shows the amount of time needed to set up everything for the bar.

 

Looks very good, cool job!

 

I hope I find the time to add it to the base source this weekend, plus writing down my thoughts about how the intro can be programmed.

 

I'm very busy the next three weeks, as I'm currently preparing a very advanced Seawolf demo for the Midwest Classic Show.

 

@BPB: You're still with us? Don't kill yourself on the kernel, if it's getting too tough, let's continue together!

 

Greetings,

Manuel

[Bad Panda Bear]

 

@BPB: You're still with us? Don't kill yourself on the kernel' date=' if it's getting too tough, let's continue together!

[/quote']

 

I'm still here. Unfortunately it's work that's been killing me, not working on the kernel. I hope to have something before I have to fly off on a business trip this wednessday, but we'll see.

[Tom]

i guess i could get rid of one scanline of setup time by using a triple copy player + its missile...with RESMP0 i could attach the missile to the player and have to call PosObject only once. after the call to PosObject i'd do a wsync/hmove, which positions the player and the missile, and then i'd need another wsync/hmove to move the missile where it actually belongs

=> 4 wsyncs instead of 5.

but then the damage bar is limited to 48 pixels, but since that's what it was intended to be in the original design i don't think this is a problem.

 

gotta try this out somewhen =)

[Cybergoth]

Hi there!

 

Main problem with the current approach not using a 6-char, is that we need the 6-char anyway for the state display, so we're wasting most scannlines because we've got to position sprites and set up things twice.

 

Besides kernel cycles and RAM, scannlines are our most valuable resource in this project.

 

Well, I hope I have time for a closer look at the weekend.

 

Greetings,

Manuel

[Tom]

so you might want to wait with integrating that code in the game.

i have started with a sixchar approach before i completed this code, but it's not yet finished.

 

with a sixchar routine it will be more difficult to calculate the data to be displayed from an energy value between 0 and 48, but it could be done pretty fast with a lookup table containing 48 entries for each of the six characters. so this would need 6*48 = 288 bytes of tables + another 6 bytes for each scanline for graphics data (if i use the same sixchar kernel for the bar as for the status display i'll have to repeat the graphics data for the damage bar for each scanline...)

 

but it's probably ways faster, so if rom isn't a problem, i'll try this approach too.

[Cybergoth]

Hi there!

 

with a sixchar routine it will be more difficult to calculate the data to be displayed from an energy value between 0 and 48' date=' but it could be done pretty fast with a lookup table containing 48 entries for each of the six characters. so this would need 6*48 = 288 bytes of tables + another 6 bytes for each scanline for graphics data.[/quote']

 

Hm... how about

 

- set all 6 pointers to a "void" sprite.

 

- while value > 7 set pointer to "solid" sprite

- subtract 8

 

- Lookup sprite for value between 0-7

 

(if i use the same sixchar kernel for the bar as for the status display i'll have to repeat the graphics data for the damage bar for each scanline...)

 

If using the alorithm above' date=' we'd end up with 9 sprites ranging from "void" to "solid", so the required ROM is 9*height.

 

but it's probably ways faster' date=' so if rom isn't a problem, i'll try this approach too.[/quote']

 

Would be cool!

 

Greetings,

Manuel

[Tom]

just for the fun of it i wrote a version of the damage bar with the RESMP0 method i described above. saved one scanline. now on to the sixchar version.

dmgbar2.zip

[Bad Panda Bear]

Well I finally managed to get some time to work on the display kernel, and I had to make a fair number of changes.

 

It quickly became apparent to me that I wasn't going to get two torpedoes positioned on one scanline. So I decided to try to alternate scanlines, i.e. position missile 0 on odd scanlines, and missile 1 on even scanlines.

 

But that meant I had to find the cycles to position the torpedo vertically and the sprites horizontally on the same scanline. In searching through the stella archives, I found out about

calculating sprite adjustments using a table. This allowed me to use positioning code like this:

 ;; Get fine adjustment into HMP0, and coarse adjustment into X

  LDA HorzTable,X    ; (4,70)

  STA HMP0           ; (3,73)

  STA WSYNC



 ;; There are 16 cycles needed from the WSYNC

 ;; to the loop. In this case I used four for the 

 ;; following code, and 12 for the positioning a 

 ;; missile  But the following four cycles could

 ;; also be moved to before the WSYNC if needed

  AND #$0F           ; (2,2)

  TAX                ; (2,4)

  VERT_POS_MISSILE 2, tempTorpedo2YPos, 1;(12,16)

.loop1

  DEX                ; (2,18+5*X)

  BPL .loop1         ; (2,20+5*X) on final loop

  STA RESP0          ; (3,23+5*X), 73 cycles at most

  STA WSYNC

  STA HMOVE

 

I had to use a different table than in the stella message linked to above, but this allowed me to position the torpedoes on alternate scanlines. The code is attached.

fireone_torpedoes_may18.zip

[Cybergoth]

Hi there!

 

It quickly became apparent to me that I wasn't going to get two torpedoes positioned on one scanline. So I decided to try to alternate scanlines, i.e. position missile 0 on odd scanlines, and missile 1 on even scanlines.

 

Hm... actually the # of scanlines for the torpedo positioning shouldn't matter at all. It can be done during VBLANK, when we have almost unlimited time for that.

 

The horizontal position of the torpedos does not change during the frame, there's only two displayed per frame. All that is needed to take care of during the display time is enabling the missiles on the right scanlines.

 

I fear I didn't explain that detail good enough. I'm sorry

 

If possible we should go back to the original positioning routine and shift the code into the VBLANK with the next update, as the table is a giant waster of ROM.

 

Other than that, the kernel already looks brilliant!

 

What would you like to do next, expanding the game world or flicker?

 

Greetings,

Manuel

[Bad Panda Bear]

I was referring to the 12 cycle vertical positioning of the torpedoes, not the horizontal positioning. I coudn't get two torpedoes enabled based on their vertical positions within the horizontal blank of a single scanline. So I used the larger table lookup method of horizontal positioning so that I could enable/disable a torpedo on the same scanlines that the player sprites are horizontally positioned on. This allowed me to enable/disable the two torpedoes on alternate scanlines since I no longer had to avoid the scanlines where the player sprites are positioned.

 

The horizontally positioning of the torpedoes is done in the VBLANK section of the code as you described. Your explanation of this was fine, it was my explanation of what I had done that was confusing. I think this is because I tend to refer to the enabling/disabling of torpedoes as vertical positioning, and I left out the word vertical. Sorry about that. I hope I was clearer up above.

 

As far as what to do next, I would like to get flicker implemented. I'm worried that four torpedoes on the screen at one time isn't enough for good gameplay, and I'd like to get flicker implemented so we can try it and find out.

 

Other things that need to be done before expanding the game world are that pesky direction arrow at the bottom, and expanding the enemy sub to use both player sprites.

[Cybergoth]

Hi there!

 

As far as what to do next, I would like to get flicker implemented. I'm worried that four torpedoes on the screen at one time isn't enough for good gameplay, and I'd like to get flicker implemented so we can try it and find out.

 

Ok, fine.

 

I have two things for discussion here.

 

For one, I think the quad sized ships look really ugly. I think we should eventually consider having the ships on top normal and the ones in the middle just double sized.

 

Then, I'm no longer sure if we should flicker the enemy ships. In theory we could as well have only two ships per row and just double the rows. More or less this'd only cost us two more calls of our subroutine.

 

Other things that need to be done before expanding the game world are that pesky direction arrow at the bottom, and expanding the enemy sub to use both player sprites.

 

The sub should be trivial.

 

For the arrow I'd suggest tables. Assuming one center position and 7 left and 7 right pointing positions, We'd do a set of tables with 15 entries each.

 

The required tables would be

 

arrowleftpos

arrowrightpos

arrowleftshape

arrowrightshape

 

More or less the main task is filling those tables with working data now

 

I'd also suggest arranging the tables from max left to center to max right.

 

So for the horizontal movement of our sub, we'd use a variable for speed that is working just like this:

 

0 -> maximum speed turn left

8 -> Don't turn

15 -> maximum speed turn right

 

And this speed variable would be used to index the tables described above for the arrow data.

 

The very same speed variable will later also index other tables responsible for the actual horizontal movement of the sub, so the arrows appearance is directly synchronized with the subs behaviour.

 

Greetings,

Manuel

[Bad Panda Bear]

I have two things for discussion here.

 

For one, I think the quad sized ships look really ugly. I think we should eventually consider having the ships on top normal and the ones in the middle just double sized.

 

Then, I'm no longer sure if we should flicker the enemy ships. In theory we could as well have only two ships per row and just double the rows. More or less this'd only cost us two more calls of our subroutine.

 

Well I drew them, so of course they're ugly. But I do think using more rows of ships is a good idea, so I did a quick version of this (see screen shot below).

 

My main concern was that the pseudo 3D effect of the game would be ruined. So I made the sprite for the horizon version of the tanker a scanline shorter to make it look more distant than the ships on the second row. For the foreground ships, I don't think it matters too much because they're closer and therefore should show less of a size difference due to distance.

 

So what do you all thinK?

[Tom]

looks much better now, and still pretty 3d-ish

[Cybergoth]

Hi there!

 

My main concern was that the pseudo 3D effect of the game would be ruined.

 

I also think it's a big improvement now

 

Part of the 3D illusion will also come when the whole system is in horizontal motion, so the effect will get even stronger in a little while.

 

Greetings,

Manuel

[Bad Panda Bear]

I've been silent about FireOne for the past several weeks, but not because I haven't been working on it. What happened is that I decided to try a simple little experiment that ended up being very complicated. As a consequence, this message is very long, and I apologize in advance for that.

 

My goal was to make the sprites look better, and I thought that using a variable NUSIZx value for each scanline might allow more detail at the top while keeping the bottom portions large (important for battleships and carriers because they are supposed to be large). In implementing this I came across a series of problems that required me to do more and more complicated stuff to get things to work.

 

Problem #1: There wasn't enough time in the horizontal blank to do two NUSIZx stores and two GRPx stores, along with the alternating missile

enabling code. I solved this by setting VDELP1. This allowed me to set GRP1 on the scanline before.

 

Problem #2: When you change NUSIZ, the sprite graphics were not aligned with the earlier portions of the sprite. To fix this, I had to set HMPx and do an HMOVE to align the bottom portion of the sprite.

 

Problem #3: Doing an HMOVE on every scanline of the sprite ruined the left edge of the display. I considered just using a smaller screen, but decided to be ambitious and try the early HMOVE trick (See the Games that do bad things to HMOVE thread on the stella list). By doing an HMOVE at cycle 73 instead of after a WSYNC, I got rid of the HMOVE blank.

 

Problem #4: I wanted the flexibility to choose different sizes at different points for the two player sprites. To do this I changed from using a spritePointer that points at each sprite, to using an 8 bit pointer from an assumed SpriteData table. Then in another 256 byte page in ROM called SizeData I have tables that control the HMPx and NUSIZx values to set for each scanline. The offset for each sprite is the same in SizeData and SpriteData, so I could use the same 8 bit pointer passed into DisplayMainStripe. The format I use has the HMPx data in the high nibble and the NUSIZx value in the low nibble. Here's an example from the first row (on the horizon) battleship sprite:

;; Row1BattleShip

   .byte %11011101

   .byte %10000000

   .byte %10000000

   .byte %10000000

   .byte %10000000

 

The sprite is still inverted, so the first few bytes have 0 movement (%1000 since HMOVE is being done at cycle 73), and single sized sprite data. On the last line, to make the sprite look longer, I used double sized sprite data. This requires a movement of 5 pixels of the left (%1101 in the high nibble)

for the botton scanline to line up where I want it to.

 

Also note that since bit 4 of the NUSIZx values aren't used by the TIA, I am using a 1 in this to indicate the end of the sprite. This saved me a

few cycles in the display routine. It also means that I don't need to invert the sprites any more, but I haven't felt like changing that yet.

 

 

Problem #5:

When horizontally positioning the sprites, they line up differently because of the various HMOVEs done when drawing the sprites. So a sprite at position 0 may be mostly off the screen if the lower scanlines are moved to the left relative to the higher scanlines. To solve this I added another ROM table, called ShipTypeData, that has offsets for each sprite just as in SpriteData and SizeData. Right now ShipTypeData just has a horizontal offset that is applied to each sprite's X coordinate before horizontally positioning the ship (This is done in the VBLANK portion of the code right now). Eventually it could also store stuff like how fast a ship goes, and how many hits it can take before it sinks. But it is very inefficient in ROM usage because in order to use same offsets as SpriteData, the closer ships use many more bytes than the distant ships, even though they don't need to in ShipTypeData. I think this needs to be done differently in the future.

 

Problem #6:

Duplicating the sprites between the bottom two rows, and the top two rows didn't give the right pseudo-3D effect that the original game did. To

fix this I made a version of each sprite for each of the four rows ships appear on. This of course requires much more ROM space. If the sprites

are to fit into 256 bytes of memory, then I calculate that the game can only support four ship types, plus a blank sprite, an arrow sprite, and the

submarine sprites. (I also ended up making the sprites a bit taller, so I had to remove the top sky slice).

 

Problem #7:

This is the one I haven't solved. When I position the ships towards the right hand side of the screen, the sprites go wacky. Now on my 2600jr I don't see this, so it might be an emulation problem. But my 2600jr looks like crap on my big screen anyway, so it's hard to see if there are any other problems with the code. Since I'm doing tricky things to HMOVE and NUSIZ, I really need to test this on my other 2600 console types (I have several) before I start blaming z26.

 

Phew. For those of you brave enough to have read this far, I have the following question: Are the new sprites (see first screen shot below) good enough to warrant all this complexity and added ROM space? I kind of like them but I'm not very artistic and don't trust my judgement in this.

fireone_src_and_bin.zip

[Tom]

Are the new sprites (see first screen shot below) good enough to warrant all this complexity and added ROM space?

 

certainly. and iirc the code is anyway prepared to be changed to f6 bankswitching in case we run out of rom space.

 

btw, i haven't worked on my stuff (damage / status bar) neither, due to university projects, but i'm still into this project.

[Cybergoth]

Hi there!

 

Well, first thing to do with this post is handing over controls to Bad Panda Bear. I think you're now way more involved with the project now than I ever was. Also I consider it mostly your baby now and I don't feel like I should be in the position of telling you what do do any longer. I'll continue my support for the project though and give all good advice I can

 

I've been silent about FireOne for the past several weeks, but not because I haven't been working on it. What happened is that I decided to try a simple little experiment that ended up being very complicated. As a consequence, this message is very long, and I apologize in advance for that.

 

Ah, that's fine. By trying all sorts of things you can learn a lot. Also if you have two options, try both and then go for the better

 

My goal was to make the sprites look better, and I thought that using a variable NUSIZx value for each scanline might allow more detail at the top while keeping the bottom portions large (important for battleships and carriers because they are supposed to be large). In implementing this I came across a series of problems that required me to do more and more complicated stuff to get things to work.

 

This idea generally has good and bad aspects. While the ships admittedly gain a lot of detail and look better with that technique, there's one thing that can get extremely complicated with this:

 

Scrolling the ships smoothly in and out at the borders of the screen...

 

Problem #3: Doing an HMOVE on every scanline of the sprite ruined the left edge of the display.  I considered just using a smaller screen, but decided to be ambitious and try the early HMOVE trick (See the Games that do bad things to HMOVE thread on the stella list).  By doing an HMOVE at cycle 73 instead of after a WSYNC, I got rid of the HMOVE blank.

 

Well, my simple, yet effective trick to the smooth screen enter/exit thing mentioned above would have been completely blacking PF0, so the ships would smoothely disappear underneath this border.

 

Problem #4: I wanted the flexibility to choose different sizes at different points for the two player sprites.  To do this I changed from using a spritePointer that points at each sprite, to using an 8 bit pointer from an assumed SpriteData table. Then in another 256 byte page in ROM called SizeData I have tables that control the HMPx and NUSIZx values to set for each scanline. The offset for each sprite is the same in SizeData and SpriteData, so I could use the same 8 bit pointer passed into DisplayMainStripe.

 

Very clever!

 

This of course requires much more ROM space. If the sprites are to fit into 256 bytes of memory, then I calculate that the game can only support four ship types, plus a blank sprite, an arrow sprite, and the submarine sprites.

 

Hm... as Tom said, ROM in general is no problem at all. One has to see how/if the gameplay is altered with 4 different types only.

 

Phew. For those of you brave enough to have read this far, I have the following question: Are the new sprites (see first screen shot below) good enough to warrant all this complexity and added ROM space?  I kind of like them but I'm not very artistic and don't trust my judgement in this.

 

There's no question, they're certainly looking better than before. But there'll most likely be a tradeoff somewhere else. Since this is another set of compromise than I originally plotted, it may complicate other things more than necessary.

 

BTW: Can there still be two ships per row at once? Just asking because the others are missing in the current binary

 

Greetings,

Manuel

[Bad Panda Bear]

Hi there!

 

Well, first thing to do with this post is handing over controls to Bad Panda Bear. I think you're now way more involved with the project now than I ever was. Also I consider it mostly your baby now and I don't feel like I should be in the position of telling you what do do any longer. I'll continue my support for the project though and give all good advice I can

 

I feel like I need some sort of official acceptance speech like "Ladies and Gentlemen of AtariAge, I humbly accept this honor..."

 

But seriously, I always thought of you as providing guidance rather than telling me what to do. But you're right, by the sheer amount of time I've invested in this projected it seems that I have practically taken control of it anyway. So it makes sense that you'd want to make that official. That being said, this started out as a low pressure environment for newbies to participate in developing a game, and I'd like that idea to continue. Tom seems to still be on board, and was it Galaga_Freak who was doing the intro? Whoever it was you are still welcome to contribute if you wish. And there are still some jobs free for anyone else who wishes to join.

 

Cybergoth, are you still willing to work on the networking code mentioned earlier in this thread? The game isn't really ready for it yet but I think it's a cool idea that I'd be willing to attempt to tackle if you don't want to.

 

For the near future though, I think I need a little break from FireOne. I've been thinking about entering the Minigame competition, and I need to clean my apartment and organize my Atari 2600 collection. Plus I've been purchasing expensive modern games and not playing them. Which makes me a saaaaad panda.

 

This idea generally has good and bad aspects. While the ships admittedly gain a lot of detail and look better with that technique, there's one thing that can get extremely complicated with this:

 

Scrolling the ships smoothly in and out at the borders of the screen...

Yes, that seems to be the Achiles heel of this technique. As a trade off it may be neccessary to not scroll the ships onto the screen but instead to have them appear in full. But I hope that can be avoided.

 

Well, my simple, yet effective trick to the smooth screen enter/exit thing mentioned above would have been completely blacking PF0, so the ships would smoothely disappear underneath this border.

I had originally wanted to keep the full 160 pixels of horizontal position, but this may be another trade off that has to be made. But regardless of this the multi-NUSIZ sprites force me to keep the early HMOVE because I needed the -15 move to the left to center the quad-sized lines underneath the single and double sized line.

 

BTW: Can there still be two ships per row at once? Just asking because the others are missing in the current binary

Yes. I blanked out the other sprites and commented out their movement so that I could test scrolling of the player 0 sprites without interference. But the code is still there, and is still being used for the submarine which is a 16 bit sprite now.

[Cybergoth]

Hi there!

 

Sorry, forgot to answer this all the time...

 

and was it Galaga_Freak who was doing the intro?

 

If he left the team, I could give this a try.

 

Cybergoth, are you still willing to work on the networking code mentioned earlier in this thread? The game isn't really ready for it yet but I think it's a cool idea that I'd be willing to attempt to tackle if you don't want to.

 

Willing: Yes

Able: Probably

 

Well, to test this, I'd need 2 SC/CC/Kroko/CC2 devices or an EPROM burner, which I don't have...

 

My plan was to meet with TJ and Oliver Achten to do this on a weekend session, yet we didn't get around to it until now.

 

We already worked out a plan and I could write the code I think, but someone would have to solder a prototype cable and try it on actual hardware...

 

I've been thinking about entering the Minigame competition

 

 

Yes, that seems to be the Achiles heel of this technique. As a trade off it may be neccessary to not scroll the ships onto the screen but instead to have them appear in full.  But I hope that can be avoided.

 

Ouch! That'd be really bad... having such big things popping in from nowhere will look weird.

 

Greetings,

Manuel

[Thomas Jentzsch]

Ouch! That'd be really bad... having such big things popping in from nowhere will look weird.

100% agreed.

 

How about making them come from the horizon? So while they move e.g. from left to right, you can only see the top of them when coming from the very left, everything around the middle and then they slowly disappear at the right.

[Cybergoth]

Hi there!

 

How about making them come from the horizon? So while they move e.g. from left to right, you can only see the top of them when coming from the very left, everything around the middle and then they slowly disappear at the right.

 

Interesting thought!

 

What I've also been thinking of, is that blacking out PF0 might still do the trick, if you get the ships to properly wrap around at the screen borders. At least if the largest ships don't exceed 32 pixels, they'd still fit underneath.

 

 

Greetings,

Manuel

[Bad Panda Bear]

Hi there!

 

Well, first thing to do with this post is handing over controls to Bad Panda Bear.

650547[/snapback]

 

...and the first thing I did with those controls was to ignore the project for nearly a year.

 

Man I suck. I blame KOTOR. And Civ 2.

 

But I've finally managed to arrange things so that I can start working on this again. Who out there is still interested? Are any of the other volunteers still out there and willing to give this a try?

 

Anyway, my next step is to try to get a smaller test program running to try to figure out the problem I had when the ships got close to the screen edges.