1942 WIP

[+splendidnut]

Alright, got some preliminary work down on allowing the player's plane to be multicolored.  (and the background color too... but that may or may not stick around)

 

Currently I've got it hard-wired to use a color data table stored in the multisprite_kernel.asm file itself.  To be able to make this more flexible, the two vars used to point to the table (player0colorPlo and player0colorPhi) will need to be moved out of temp locations into more permanent locations residing in the zeropage.  This will probably involve moving some other variables around potentially into Superchip RAM. 

 

I'm not sure how feasible that is, but there seems to be some space available there.  I'm guessing that your playfield scrolling technique actually freed up a lot of Superchip RAM that would have otherwise been used to hold the playfield data.

 

I've already some of this seemingly unused RAM to store the sorted list of Y coords used by the shared sprites.  This allowed me to free up the cycles needed to add the player color lookup in the main kernel.

 

There's still some tweaking that needs to be done.  But ultimately, things seem to be working ok.

 

This has been committed to my fork on Github.  Let me know if you find any issues with this.

 

Enjoy.

[+splendidnut]

Might as well show a teaser screenshot:   (Ignore the background color change line....and the fact that it's a bit garbage... this mainly was a hack to let me see when one of the kernel labels was being hit... It may not be feasible to keep around.)

 

 

 

Here's without the background color changes:

 

 

[+sramirez2008]

Wow!  I really like the screenshot without the background color changes.

[orange808]

1 hour ago, splendidnut said:

Might as well show a teaser screenshot:   (Ignore the background color change line....and the fact that it's a bit garbage... this mainly was a hack to let me see when one of the kernel labels was being hit... It may not be feasible to keep around.)

Did you remove background color changes completely?

 

Does 1942 use the background color feature?

[+splendidnut]

There were no background color changes within the multisprite display kernel.  It was spare time that was just being wasted with a sleep when the kernel didn't have to decrement the playfield row count register (the KernelLoopA loop point):

    ;---- Actual display kernel starts here

;--- KernelLoopA is hit 3 out of 4 scanlines

KernelLoopA                 ;----- enter at 53
    ;SLEEP 7                     ;7  [60]
    
    ;---- this is just some temp code to show where KernelA is hit.
    eor     #$9F
    and     #$97
    sta     COLUBK

;--- KernelLoopB is only hit 1 out of 4 scanlines
;-
;--         -- DRAWING line 1 -> player0, player1, playfield

KernelLoopB                 ;----- enter at 60

When KernelLoopA is hit, the Accumulator contains the current display line (2px scanline) used for sprite graphics/color data lookup.

 

There might be potential here to do a more subtle color change effect... I might have to play around a bit more with it.

 

I apologize if the screenshots were misleading... they just happened to be taken at two different locations, one with an island and one without.

 

------

Addendum:

 

I got to thinking more about this and realized the code comments are still wrong... it's a 2 line kernel and I believe during the majority of the game, the kernel pfheight is set to 1.  That would mean the kernel flip flops evenly between hitting KernelLoopA and KernelLoopB... so my background color hack would be getting hit every other set of 2 scanlines... leading to the 4 scanline blocks of color seen in the "bg color changing" screenshot.

[orange808]

Never mind.  ?

Edited June 7, 2022 by orange808

[+splendidnut]

I'm not sure I follow.  Could you elaborate a bit on that?

[+splendidnut]

I've been off on vacation and got a little bit of work done... mainly being able to rework the multi-sprite kernel to hack together a method for adding color to the multi-sprites.  The work involved:  disable the ball sprite code, rework the playfield data loading to be more direct and not need a cache, slip in color loading/changing code for the shared sprite, and finally re-enabling the ball sprite code.  It was quite the process.

 

THE RESULTS:

Green enemy planes look pretty good, but the rest of the things don't:  red planes (and bullets) look like candy canes and the ship details look like garbage.  Those two issues are mainly due to the method I used for hacking in color support:  doing an OR operation between a line-by-line color table and the original color of the sprite.  This method was an "easy" way to add color support without needing to setup a bunch of color tables or use any extra RAM besides a couple of temp variables.  Also, it was quite a minor change within the Repositioning Kernel which doesn't have a lot of wiggle room to work with.

 

NEXT:

I'm still tossing around ideas of how to proceed.  While switching to a pointer-based color table selection like the sprite graphics would be the most flexible, it would require a lot of reworking of the repositioning kernel to work.  My current line of I'm thinking is that switching to an "indexed" based line-by-line color table leveraging the selected COLUPx values as the index, would be the way to go.  That would require going thru the BASIC code to determine what color tables are needed and then switching all the code for sprite colors to be indexes into that color table.  BUT it should fit in nicely with what I'm currently doing.

 

If anyone has any other thoughts on this, please let me know.  The code for this is in my fork on Github:  https://github.com/splendidnut/1942-bB

 

ANYWAYS, here's a BIN and some screen shots:

 

1942_HSC-color-experiments.bin

 

 

 

Enjoy!

 

 

[LatchKeyKid]

It's an enjoyable game so far and visually impressive for the 2600!  I'd probably say the enemy fire looks more like incoming candy corn personally though and not candy canes. 

 

I'm new to the 2600 scene and shocked at how people can squeeze out the power that they can from the classic system after watching the 8blit series of coding videos on youtube.  Just managing the two player sprites on the same line is possible but only if coded a certain way which was shocking to me.   As a noob, would increasing the size of the sprites to a two line kernel give you a bit more wiggle room with CPU cycles to do more of what you need?  I'd personally be fine with that myself asthetically as a player new to the game.

[+splendidnut]

This uses the bBasic multi-sprite kernel which is already a 2-line kernel.   For multi-sprite support, it also utilizes a separate 4-line display kernel that has to interleave the repositioning and loading of the next sprite with everything (excluding the sprite 1) that the 2-line kernel does.  That 4-line kernel is super tight code-wise... and was/is the biggest hurdle in reworking things.

 

The coloring of the sprites is offset from the sprite graphics by 1 line... which kinda gives the appearance that it's single line kernel.  That just happened to be the easiest place to add the "line-by-line" coloring.  It's a fun little trick

 

Utilizing DPC+ would allow total single-line resolution, but that's a non-starter for various reasons stated earlier.  I'm perfectly happy to work without it as there's still a lot of territory to explore without it.  I'm quite happy with the results I've gotten so far.

 

This is still a work in progress... I'm the kind of person that likes to share the in-between work to show how things evolve.

[LatchKeyKid]

I appreciate the info and breakdown.  What on screen benefits does that 4 line display kernel give you that the player would notice?  More sprites on screen on different or same scanlines?   I did read tha the graphical offset by one line is treated by the TIA as a single line (?) as the engineers who designed it knew the limited CPU cycles would be an issue for programmers though I obviously can't say personally from experience if it is true.  I do like the idea of changing colors along the sprite; is the process limited to similar colors like you have on the aircraft sprites now or could you feasibly use it also to add a darker "cockpit" color to one line?  Apologies again as I'm a noob and don't necessarily know the correct terminology let alone the coding behind it.  Admittedly that may cause a redesign of some sprites so you don't have random portions of the rest of the aircraft the same color though.

 

From a player perspective, is there any on screen or audible clue that a big bomber is coming in from the bottom of the screen?  That seemed to be the most common way for me to die and my 8 year old self that played the 194x games on NES would be complaining about the "cheesiness" of the death.     It's been a while since I played the classic games so I don't recall if that is a thing in the franchise of games.

Edited June 20, 2022 by LatchKeyKid

[+Al_Nafuur]

6 minutes ago, LatchKeyKid said:

From a player perspective, is there any on screen or audible clue that a big bomber is coming in from the bottom of the screen?  That seemed to be the most common way for me to die and my 8 year old self that played the 194x games on NES would be complaining about the "cheesiness" of the death. 

StrategyWiki has this hint for the Arcade version:

https://strategywiki.org/wiki/1942/Walkthrough#Stay_away_from_the_bottom

 

I have tried to implement this in our 1942 version as authentically as possible.

 

It is mentioned in our (copied) wiki too:

https://github.com/Al-Nafuur/1942-bB/wiki/Walkthrough#stay-away-from-the-bottom

 

 

[+splendidnut]

1 hour ago, LatchKeyKid said:

What on screen benefits does that 4 line display kernel give you that the player would notice?  More sprites on screen on different or same scanlines?

TLDR:  Both.  More on-screen sprites in general.  They will flicker only if vertically close... if they're all vertically separated, there will be no flicker.

 

----

 

To clarify a bit more, the 4-line display kernel that I mentioned earlier is actually two copies of the 2-line kernel in succession.  The copied code has been modified to contain the code necessary to reposition (which requires a full line to perform) and load information for a new sprite (uses a big chunk of another line)...to support reusing one of the TIA's sprites.  The on-screen benefit is more sprites, with minimal flicker if they are separated vertically.

The current multi-color solution I've hacked in does limit things to how they appear now... ala.. the cause of the red sprites looking like candy-canes.  That can be tweaked a bit...  But is better off being remedied by the solution I've proposed earlier:  adding more "color" sets chosen based on an index value derived from the RAM-stored "color register".  The big downside to the solution is that it's a single table so it's not as flexible as the sprite graphics which use pointers.

The more general solution would be to add pointer-based color-lookup (similar to how the sprite graphics are handled)... but that would require RAM and enough time in the "4-line display and swap sprite" kernel to support it.  Also, it would probably require compromises to be supported via display options.  For example:  giving the use the choice between (1) use of the ball object OR (2) having multi-color sprites.  Ultimately, that would be beneficial to any bBasic game in the long run, but would be a lot of work.

With the modifications I've made to the display kernel for this game, I've already made some assumptions that won't necessarily work well for general use-cases.  BUT, that is fundamentally how to make the very best-looking Atari 2600 games, by making game-specific drawing kernels.

[LatchKeyKid]

7 hours ago, Al_Nafuur said:

StrategyWiki has this hint for the Arcade version:

https://strategywiki.org/wiki/1942/Walkthrough#Stay_away_from_the_bottom

 

I have tried to implement this in our 1942 version as authentically as possible.

 

It is mentioned in our (copied) wiki too:

https://github.com/Al-Nafuur/1942-bB/wiki/Walkthrough#stay-away-from-the-bottom

 

 

Thanks.  I figured there was a good chance that it was a feature and not a bug to prevent exactly what I was doing (playing Galaga 1942!). 

 

 

5 hours ago, splendidnut said:

TLDR:  Both.  More on-screen sprites in general.  They will flicker only if vertically close... if they're all vertically separated, there will be no flicker.

 

----

Spoiler

 

To clarify a bit more, the 4-line display kernel that I mentioned earlier is actually two copies of the 2-line kernel in succession.  The copied code has been modified to contain the code necessary to reposition (which requires a full line to perform) and load information for a new sprite (uses a big chunk of another line)...to support reusing one of the TIA's sprites.  The on-screen benefit is more sprites, with minimal flicker if they are separated vertically.

The current multi-color solution I've hacked in does limit things to how they appear now... ala.. the cause of the red sprites looking like candy-canes.  That can be tweaked a bit...  But is better off being remedied by the solution I've proposed earlier:  adding more "color" sets chosen based on an index value derived from the RAM-stored "color register".  The big downside to the solution is that it's a single table so it's not as flexible as the sprite graphics which use pointers.

The more general solution would be to add pointer-based color-lookup (similar to how the sprite graphics are handled)... but that would require RAM and enough time in the "4-line display and swap sprite" kernel to support it.  Also, it would probably require compromises to be supported via display options.  For example:  giving the use the choice between (1) use of the ball object OR (2) having multi-color sprites.  Ultimately, that would be beneficial to any bBasic game in the long run, but would be a lot of work.

With the modifications I've made to the display kernel for this game, I've already made some assumptions that won't necessarily work well for general use-cases.  BUT, that is fundamentally how to make the very best-looking Atari 2600 games, by making game-specific drawing kernels.

 

 

I appreciate the info.  It's really impressive to see up to 15 (so far my highest noted count) enemy planes on screen at once moving in formation and at least 9 moving in other scenarios in different directions. 

[+splendidnut]

Making some progress with getting things properly colored:

 

 

 

I've created a color table to contain the color sets needed for each different type of sprite.  The sprite "color register" variables (COLUP1..COLUP5) get used as indexes into the color table.  I've filled in the color table for the some of the sprites... but there's still others to do.

 

There is a minor flaw in the kernel that causes some color flickering (can be see on the head/tails of the red planes in the screenshot above).  This happens because the kernel sets the color of a new sprite after it's already drawn the first graphics line.  An "easy" solution to that would be to pad out all sprites by a line.

 

The other issue I'm aware of involves the player sprite color not being updated when a repositioning line passes thru it.  When this happens, it appears like something passed over the plane causing a momentary shadow.  It's kind of cool looking... which is good because I don't think there's an easy fix for that.

 

Anyways... changes committed to Github and here's an NTSC binary for you to enjoy:

 

1942_HSC-color-exp-20220622.bin

 

[+sramirez2008]

Those sprites are looking really good.

[+ZeroPage Homebrew]

2 hours ago, splendidnut said:

Making some progress with getting things properly colored:

The colours look amazing, great update @splendidnut! This port is getting better and better by leaps and bounds all the time!

 

- James

[Prizrak]

Looks great@splendidnut this adds a nice polish that it was missing. The port is already amazing but this kicks it up a notch.

Sent from my SM-G996U using Tapatalk

[LatchKeyKid]

2 hours ago, splendidnut said:

Anyways... changes committed to Github and here's an NTSC binary for you to enjoy:

 

1942_HSC-color-exp-20220622.bin 32 kB · 5 downloads

 

Looking good.  Did you disable the powerups or did I just get really unlucky in my playthrough for about 10 minutes just now?

[+splendidnut]

1 hour ago, LatchKeyKid said:

Did you disable the powerups or did I just get really unlucky in my playthrough for about 10 minutes just now?

Yeah, I just noticed that myself... It probably happened on accident.  I know some of the code relies on certain color values indicating certain states... I'll have to dig around.

 

ADDENDUM:

Yup, color of the last explosion frame is used in the logic to determine if a power-up is shown... I'll need to figure out a fix for that.

[+Al_Nafuur]

1 hour ago, splendidnut said:

Yeah, I just noticed that myself... It probably happened on accident.  I know some of the code relies on certain color values indicating certain states... I'll have to dig around.

 

ADDENDUM:

Yup, color of the last explosion frame is used in the logic to determine if a power-up is shown... I'll need to figure out a fix for that.

The powerups (and the carrier superstructures) should be a single color.

 

[+splendidnut]

Alright, I've got most everything properly colored now... and I believe I fixed the issue with the power-ups.  I'm not exactly sure of the logic involved with that, but I had to add a "wrap-around" to the bonus counter to stop bad values from screwing up the kernel.

 

I've put the code on Github, with a pull request to @Al_Nafuur's main branch.  I'm still going to fiddle around and try to fix some remaining issues, but I figured I accomplished the majority of the work, so it was time to fold it back in.  Please let me know if there is anything that needs to be corrected.  One thing that pops in my head is needing to handle PAL vs NTSC colors.

 

Please feel free to provide any feedback / suggestions.

 

Enjoy (NTSC binary)!

 

1942_HSC-color-exp-20220624.bin

[+Al_Nafuur]

35 minutes ago, splendidnut said:

Alright, I've got most everything properly colored now... and I believe I fixed the issue with the power-ups.  I'm not exactly sure of the logic involved with that, but I had to add a "wrap-around" to the bonus counter to stop bad values from screwing up the kernel.

 

I've put the code on Github, with a pull request to @Al_Nafuur's main branch.  I'm still going to fiddle around and try to fix some remaining issues, but I figured I accomplished the majority of the work, so it was time to fold it back in.  Please let me know if there is anything that needs to be corrected.  One thing that pops in my head is needing to handle PAL vs NTSC colors.

 

Please feel free to provide any feedback / suggestions.

 

The PowerUps don't work correctly anymore all PowerUps are now the "Quad Gun" Pow. Also the Pow dosen't appear when the last red plane shot down is moving upwards.

 

https://github.com/Al-Nafuur/1942-bB/wiki/How-to-play#PowerUps

 

 

 

 

[+splendidnut]

Yeah, I was afraid of that.  I found the logic surrounding the _stage_bonus_counter to be non-intuitive, so I only tweaked things to prevent the kernel from going bonkers.  I'll look into fixing that.

[+Gemintronic]

Sorry if this has already been covered.  If I try to compile the source folder it gives me a:

 

 error: Unknown Mnemonic 'SET_PLUSROM_API'.

 

Are there more files needed?  Or, a special variant of bB or DASM?