Jump to content
IGNORED

Powerglove


Lazycow

Recommended Posts

Hello Atariagers,

recently, I am thinking about porting the game "Powerglove" to the Atari VCS.

more infos: http://www.lazycow.de/powerglove

 

There're not many simultanously moving objects in the game and most of the sprites are displaced vertically, so I think it could be possible to port it. (Powerglove is a 16k game for the C64 from 2013, which scored the 3rd place in the RGCD compo, so it's probably not too shabby)

2OFU5fW.png - tKiFzoa.png

C64 screenshots (left), Atari VCS mockups (right)

 

Yes, these are only mockups! In the 1st step, I only want to check how it would look like on the Atari. I have not decided if I really want to start programming. (If someone is interested into a cooperation, feel free to tell me)

Some tricks used in the mockup:
- I decided to cut off two rows in the playfield, to fit it in the 192 lines.
- 48 clock sprite trick: for the top status display and the title
- in the playfield, every 16th line is blank (to reset sprites and load new background)

Some rooms have vertical scrolling (which is essential) and other rooms have horizontal scrolling (which could be ommited).

Do you think it would work like that?

  • Like 6
Link to comment
Share on other sites

Your mockups look possible. The score display is the most complicated part of the kernel. I think it is possible. I would use an unrolled loop and write each line on its own. You have to use the missiles to get the highlight on the sides. They will be in triplicate mode because they follow the players # of copies. You will need to enable and disable them at the right times to avoid drawing more then one. You need to strobe HMOVE on certain lines to reposition the highlights. I think this is all possible even with the 76 cycles per scanline constraint. With an unrolled loop you could put 1 or more digits into ram and directly load it line by line. The index could be loaded immediately line by line. You could also use the value of the index to enable or disable the missiles, by interlacing the graphics in the rom. By this I mean use Y=2,3,6,7,10,11, etc.. as that value could all be use to ENAMx. So you just have to spread the graphics out in the rom to use said indexing. Conversely you could use Y=0,1,4,5,8,9 etc... to disable the missiles instead.

Link to comment
Share on other sites

Oh, that donkey kong looks impressive. I think I have even spotted moving background elements there.

 

Good point Omegamatrix, I didn't recognice that the missiles will be trippled, too. Seems like that the only way to check if this setup is possible would be to program a kernal. Thanks for the feedback! I will post here again in case I will do an update...

Link to comment
Share on other sites

Oh, that donkey kong looks impressive. I think I have even spotted moving background elements there.

 

Good point Omegamatrix, I didn't recognice that the missiles will be trippled, too. Seems like that the only way to check if this setup is possible would be to program a kernal. Thanks for the feedback! I will post here again in case I will do an update...

Lazycow,

You may not need to program a kernel to do those things - bB and DPC+ are great options for making a colourful game if you want to omit the scrolling as you mentioned.

 

The ASDK Assembly framework is another option (and possible to use with bB) that can tripple the missiles, double the players and do the horizontal/vertical scrolling the game is doing. It's fast to write with, especially if you're used to coding asm on the c64!

 

Awesome you are doing this game! Looking forward :)

Link to comment
Share on other sites

Sorry if I sounded like I'd consider dpc+ 'shameful'. Of course its not.

It's just not what I prefer in 2600 coding. I doubt it is what he wants either, but that's his call of course.

If I want something new and fancy, I (personally) would not go for the 2600.

But of course if the goal is to just get something done, any approach is valid.

Maybe its "I want my ideas executed on the 2600" vs. "I want to code for the 2600".

Edited by enthusi
  • Like 1
Link to comment
Share on other sites

We are not that quick on the trigger. (haven't decided if I really start programming, yet) Thanks for all the infos, I didn't know about the ASDK. (Seems like the ASDK would require harmony/melody hardware. Is this correct?)

lazycow,

the latest version of the ASDK supports making Atari games on tape! :)

 

Also I had misunderstood what Omegamatrix meant about trippling the missiles via TIA setting, you can use those settings with the ASDK but it also supports trippling in the sense of creating three seperate sprites from each missile object that can be positioned anywhere and four character sprites from the two sprite objects.

 

No vertical displacement is required, they can occupy the same scanlines without flicker; I'll send you a WIP build of my latest game to illustrate.

 

Watched the vid of PowerGlove, awesome game and SID tune!!! I'm going to play it on my breadbox to really enjoy the phat sound; putting it on my UIEC (have loader for cart images) :)

Link to comment
Share on other sites

Sorry if I sounded like I'd consider dpc+ 'shameful'. Of course its not.

It's just not what I prefer in 2600 coding. I doubt it is what he wants either, but that's his call of course.

If I want something new and fancy, I (personally) would not go for the 2600.

But of course if the goal is to just get something done, any approach is valid.

Maybe its "I want my ideas executed on the 2600" vs. "I want to code for the 2600".

enthusi,

I think straight bB (without the DPC+ kernel and the Visual IDE) and the ASDK Frameworks would have fit right into 80's development culture; ET and Raiders were both written with Frameworks.

 

Frameworks are as retro as Assembly and BASIC, they just offer the advantage of abstract development; IMO this isn't new and fancy, just a library of routines.

 

I prefer not to use IDE's, the Stella debugger or even Macro's because they aren't retro; there were no lightweight Macro scripting languages in the 80's beyond Logo :)

  • Like 1
Link to comment
Share on other sites

Thanks for the discussion.

Sure, I actually do not care how people reach their goals. I write all the tools I use myself usually (which is why sometimes they are worse than what's available ;-)

I love to fight for bytes and knowing exactly of every byte where it is in the binary and why etc.

I therefor dont even use macros. That aint 'elite' or 'smart' or whatever, its just my way.

Writing a game in a LIMITING framework such as BBASIC (which I really dont know much about) is something I would NOT suggest to someone who is quite likely capable of dealing with all aspects of the 2600 himself.

To me, basic seems to be a tool to simplify the process of coding. After all its Beginner's All Purpose Symbolic... Quite the opposite of Assembler when you think of it.

DPC+ (to me) is just a quick and cheap way of reducing the restrictions from the basic-approach.

Same goes for extra RAM etc... (in my world :)

There is a thin line somewhere. BoulderDash clearly would not have been possible without the extra hardware, and its used not for cheating but for a 1:1 improvement of what-can-be-done and not how-it-can-be-done.

A 6 digit score in assembler from scratch: still cool.

A 10 digit score running from ARM: not my cup.

(personal taste here)

So I dont 'judge' people for they preferred way, I just really HOPE (for my own good/interest ;-) that Lazycow (and others) take a deep breath and dive into the depth of pure Atari coding (by pure I dont mean punch hole cards but a vanilla 2600 in hardware).

I'd find it equally understandable if theloon hopes for someone to max out the capabilities of DPC+, bataribasic and a 128 KB cart, its just not my hope ;-)

Edited by enthusi
Link to comment
Share on other sites

BoulderDash clearly would not have been possible without the extra hardware, and its used not for cheating but for a 1:1 improvement of what-can-be-done and not how-it-can-be-done.

 

The ONLY "extra hardware" Boulder Dash requires is some RAM.

The bankswitch scheme is run of the mill and could have easily been in any game back in the '80s.

Link to comment
Share on other sites

Oh, Im aware of that. I connected that line to the 'extra RAM' mentioned the sentence before.

And as I said. Its more than obvious how you two made proper use of the extra RAM (its quite amazing it works WITH that RAM ;-) instead of just abusing it as a cheap work around.

My own implementation of a boulder-dash like engine for the C64 certainly required more writable memory :)

Link to comment
Share on other sites

 

The ONLY "extra hardware" Boulder Dash requires is some RAM.

The bankswitch scheme is run of the mill and could have easily been in any game back in the '80s.

 

I don't care how many times you repeat that same paragraph. I refuse to believe orphans weren't used in the process of making a tile based engine for the 2600!

 

Link to comment
Share on other sites

So I dont 'judge' people for they preferred way

[...]

[...]

And as I said. Its more than obvious how you two made proper use of the extra RAM (its quite amazing it works WITH that RAM ;-) instead of just abusing it as a cheap work around.

[...]

Words like "abusing" and "cheap work around" in reference to other peoples "preferred way", and deeming an alternate approach as "proper", belies that you do in-fact judge them. Please try not to use this inflammatory language if you truly don't mean to judge.

 

Development time is one of the limited resources we face when we're working on the 2600. Trading RAM or ROM for development time isn't a "cheap work around". Not all of us need to climb the mountain the same way, nor do we all feel that we need to pretend that Atari development stopped in 1980.

 

Apologies for continuing the sidetracking of your thread, Lazycow. Its my first and last word on the matter.

 

I think your mock-up looks great, so please don't be discouraged by the nerd fight. Whichever approach you choose, do keep us updated on your progress. This looks like it could be a fun port! :)

Link to comment
Share on other sites

I dont judge people but I do 'judge' or rather have my opinion on people's way of course.

To me 'proper usage' of RAM means efficient use. I consider a 100 MB printer driver bad. Independant of its motives.

And I think you described pretty much what I meant by 'cheap work around': do it the long, hard way or the quicker and simpler way.

You mention time as a rare resource (I couldnt agree more). Maybe we got a little misunderstanding due to my term 'cheap'.

I am no native speaker and with cheap I mean 'easy, quick, at little cost' and not 'lame'.

And you are right 'abusing' is an (overly) critical term. Meant as in non-efficient usage of RAM == abuse of RAM. I.e. doing in 256 Bytes of RAM what could be done in 128.

That is a bit over the top may be and you will find many many 'cheap' solutions for problems in my code as well of course.

In general I apologize if anyone felt offended by my wording.

Im not anti-basic Im just very much non-pro. I see no reason for people to use it unless using it is the only option.

It really wasnt my intention to offend or depreciate anyone. In fact I enjoy and encourage some discussion on this.

That being said, if anyone opens a dedicated thread, I am there.

Back to Powerglove:

To me it looks like the main engine kernel is the most important thing - and also the one that would allow for the least cuts.

If in the end the title isnt done using all missiles, players and that extra portion of trickery it wont do too much harm.

But if the game lacks enemies, it would ;-)

It could be a fun exercise to get a tiny routine running that just does what you described in your first post.

player, 1 enemy on same horizontal level, multiple enemies, asymmetric playfield.

Next could be color update of players every line (that might be a bit tight?) and playfield update.

Not with final gfx (though I envy you for being a coder and not sucking at gfx *g*) but any random/solid placeholders.

And yes, please keep everyone posted :)

Edited by enthusi
  • Like 1
Link to comment
Share on other sites

First let me say that my position is very close to enthusi's. My personal taste prefers to stay close to the limits existing back then and because I am a complete nerd here, I would also never do a Basic project.

 

Nevertheless, I have been participating in quite a lot of projects lately, which were far beyond those self-imposed restrictions. From the extra RAM in BD, over the on-cart high score saving in Star Castle Arcade to Stay Frosty 2 and Space Rocks which are effectively C programs running on ARM feeding a 6507 kernel. That has widened my perspective and also can now much easier evaluate the results.

 

E.g using an ARM doesn't let the problems disappear. You just have very different problems to solve. I am pretty sure the same is true for Basic.

 

Anyway, personally I still prefer to stay close to the original limits (I loved doing 1K games). The challenge there suits me most, the further I get away from bits and bytes, the closer I get to my every day job. I also encourage everyone to follow my way (at least once) if he wants a more true retro developing experience. But I will not judge anyone for doing different.

 

I will just judge everyone for the result. :)

  • Like 2
Link to comment
Share on other sites

Tom and Andrew,
Agree 100% it's the results/awesomeness of the game that matters the most and BD is fantastic! :)

 

But to answer enthusi's retroness query we should consider:

 

BD relies heavily on Macro's for precalculations from discussion; could you rewrite it without the Macro Assembler? Using Atari's late MA would place the game in development in 1987 so a 1989 release would be emminent otherwise.

 

Could you reduce the size to 32k with less levels if your manager cried that 64k was not possible?

 

Also how much extra RAM does BoulderDash utilise?

 

My ASDK utilises 256 bytes of either CBS RAM or SuperCharger RAM which would place the Framework technology aound 1982 while some versions of bB (non DPC+) could be 70's retro; definitely the 1 & 2K mini-games as well.

 

This is interesting! Hope lazycow does not mind the discussion drifting - it's good to see the different perspectives developers have :)

 

Link to comment
Share on other sites

Tom and Andrew,

Agree 100% it's the results/awesomeness of the game that matters the most and BD is fantastic! :)

 

But to answer enthusi's retroness query we should consider:

 

BD relies heavily on Macro's for precalculations from discussion; could you rewrite it without the Macro Assembler? Using Atari's late MA would place the game in development in 1987 so a 1989 release would be emminent otherwise.

 

Could you reduce the size to 32k with less levels if your manager cried that 64k was not possible?

 

Also how much extra RAM does BoulderDash utilise?

 

My ASDK utilises 256 bytes of either CBS RAM or SuperCharger RAM which would place the Framework technology aound 1982 while some versions of bB (non DPC+) could be 70's retro; definitely the 1 & 2K mini-games as well.

 

This is interesting! Hope lazycow does not mind the discussion drifting - it's good to see the different perspectives developers have :)

 

 

Macros schmacros. There's nothing special about a macro; it's just a shortcut to make things a bit more succinct when writing stuff. Yes, I could easily rewrite without macros. In fact, just take the listing file and there you go -- there's your code without macros. Macros are irrelevant when considering code do-ability. BD size is somewhat dependent on the bankswitch scheme I chose (3E). It's not the greatest of schemes and leads to huge inefficiencies in ROM usage; particularly, character shapes have to be duplicated in many banks and accessing data is sometimes a matter of complex juggling of banks to get what you want. It's slow, code intensive, and CPU time intensive. An alternate scheme would make a huge difference.

BD is not 64K. It's 32K, and most of that is unused. The game could easily be way under 16K, with ALL levels present, and RAM requirements would be around 8K with an ideal bankswitch scheme. Current RAM usage is about 12K IIRC. But that's rather misleading, because of the bankswitch scheme a lot of that RAM is actually duplicated CODE which resides in self-modifying code/RAM banks. For example, 8 rows on the screen each have their own dedicated 1K bank of RAM, and that 1K not only holds some of the character shapes for the row, but it also holds the screen bitmap for the row, AND the code that does the drawing for that row. So the drawing code is repeated 8 times. This is all mandated by the 1K bank size of RAM in the 3E scheme. When you start dealing with colour 'character tiles' which are rather large, you start to require large 'bitmaps' to hold them.

In summary, though, Thomas and I are reasonably confident with a modified bankswitch scheme, BD with dozens of levels can run in about 8-16K ROM and 4-8K RAM. Thereabouts.

FREE BYTES IN ZERO PAGE =  $4
 FREE RAM IN BANK_OBJSTACK =  $180
 BANK_MUSIC1 (2K) SIZE =  $45c , FREE= $3a4
 COPYRIGHT (2K) SIZE =  $7f9 , FREE= $7
 @ $f100 : $d
 @ $f400 : $15
 @ $f500 : $6c
 @ $f600 : $6f
 @ $f700 : $75
 Free bytes in TITLE_BANK: $be
 TITLE_BANK (2K) SIZE =  $7b7 , FREE= $49
 PAGE BREAK INSERTED FOR  FSSlogo
 REQUESTED SIZE =  $ba
 WASTED SPACE =  $25
 PAGEBREAK LOCATION =  $f300
 @ $f400 : $46
 DEMO_BANK (2K) SIZE =  $64d , FREE= $1b3
 ROM_SHADOW_OF_RAMBANK_CODE (1K) (1K) SIZE =  $3f0 , FREE= $10
 ROM_SHADOW_OF_RAMBANK_CODE -- full 2K (2K) SIZE =  $685 , FREE= $17b
 ROM_SHADOW_OF_BANK_DRAW_BUFFERS (1K) SIZE =  $3d4 , FREE= $2c
 ROM_SHADOW_OF_BANK_DRAW_BUFFERS -- full 2K (2K) SIZE =  $71f , FREE= $e1
 ROM_SHADOW_OF_BANK_SCORING (1K) SIZE =  $3ff , FREE= $1
 ROM_SHADOW_OF_BANK_SCORING -- full 2K (2K) SIZE =  $55d , FREE= $2a3
 GENERIC_BANK_1 (DECODE_CAVE) (1K) SIZE =  $3fe , FREE= $2
 GENERIC_BANK_1 -- full 2K (2K) SIZE =  $7cc , FREE= $34
 INITBANK (2K) SIZE =  $71c , FREE= $e4
 FREE BYTES IN FIXED BANK =  $62

Complete.
  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...

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