PM multiplexor

[andym00]

look on page 6 and 7... all developed when reading and studing the Ultimate iso engines...

 

http://www.atariage....20evil__st__150

 

Ah, I'd forgotten about that thread of yours

[snicklin]

Well, your attention to detail is the thing that will make it a great version of the game - I had a look at the PC Engine version, and if you made a version with no background at all it would still be amazing.

 

( I keep wondering what the XL would have been like if it had been designed with Beeb style components ... more bandwidth, 160 pixel GTIA modes )

 

I just took a look at the PC Engine version on Youtube and it looks pretty much the same as the arcade version. There appears to be faster firing when you are in the triple gun mode but apart from that and a couple of sounds slightly different, it seems the same.

[Heaven/TQA]

look on page 6 and 7... all developed when reading and studing the Ultimate iso engines...

 

http://www.atariage....20evil__st__150

 

Ah, I'd forgotten about that thread of yours

 

me, too... considering that the first drafts of the game were done in 2006... (oh my god...)

[andym00]

Look at you knowing all the names of the characters! I think you mentioned before that you've got hold of some code, where was that from?

 

I remember watching a TV programme about game making several years back now and they said that with the 16 bit versions they made them as similar to the arcade versions as possible. And with 8 bit versions, they just tried to keep "the feel" of the arcade version. This is very much what you'll be doing, as you mention the amount of colours being not possible on the A8. Like you say - if you can keep that feel, then this is what matters and you should be more than a happy bunny.

 

If I wasn't so busy with my own project, I'd be asking if you wanted some help with yours.

 

You mention that you've got lots of little bits of code ready, which bits do you have? Do you have some pretty standard sections of code that you use across projects or is it all hand-crafted per project?

 

I just read the manual The much despised 7800 version is floating around on AA somewhere, and there's also the code to an arcade version on the Japanese side of the internet somewhere though I've lost the link to that, though it might have been a disassembly instead of the original.. And back in the late 80s I saw the source code to Galaga'88 when the company I worked for were developing PCE dev kits Sadly I didn't think to snaffle a copy of it since I didn't think I'd be wanting it 20 years later

 

I think it'll look good, especially on a real TV, since a lot of the background don't really require a lot of colours to make them work well.. I know I'm just a programmer, but I've seen enough of those style of graphics and the pictures in my head of how it would work to know that it would look not just okay, but really quite good.. I mean the style of it suits it, with its darker backgrounds, which can be done well especially taking advantage of PAL, though this does leave me worrying how bad they're going to work on NTSC, but that's just one of the hurdles I guess..

 

As for the code that's ready, there's about 10 different software sprite routines & 8 different multiplexers which are all slowly distilling into one code-base for this as ideas pop into my head, though I've been idle for the last few months thanks to real-life things, but I've just got a bit a of surge on again and now just want to finally decide on everything that will go into it.. The only other code is the beginnings of the framework for the logic for the different fellas up in the formation, and also writing the train code..

 

But there's no real collection of code that I rely on, I just tend to write everything from scratch since it tends to get rather specialised for each thing.. I'd like to once and for all make, say, a multiplexer that does everything and is as fast as you would ever need, but that's never going to happen in reality because there's always some specialisation you can do to it to make it faster given the constraints of it's current use.. Plus each rewrite of something is always better than the last anyway

[andym00]

look on page 6 and 7... all developed when reading and studing the Ultimate iso engines...

 

http://www.atariage....20evil__st__150

 

Ah, I'd forgotten about that thread of yours

 

me, too... considering that the first drafts of the game were done in 2006... (oh my god...)

 

So when's the launch party then

[andym00]

Well, your attention to detail is the thing that will make it a great version of the game - I had a look at the PC Engine version, and if you made a version with no background at all it would still be amazing.

 

( I keep wondering what the XL would have been like if it had been designed with Beeb style components ... more bandwidth, 160 pixel GTIA modes )

 

I just took a look at the PC Engine version on Youtube and it looks pretty much the same as the arcade version. There appears to be faster firing when you are in the triple gun mode but apart from that and a couple of sounds slightly different, it seems the same.

 

 

It seems to be very close apart from the screen size.. I don't know if there more tricks hidden in the arcade version than the PCE version had (such the galactic bonus in galactic dancing), or if the PCE version actually added its own because I've barely played the arcade version at all, but all that's something for further down the road

 

 

[snicklin]

...

 

But there's no real collection of code that I rely on, I just tend to write everything from scratch since it tends to get rather specialised for each thing.. I'd like to once and for all make, say, a multiplexer that does everything and is as fast as you would ever need, but that's never going to happen in reality because there's always some specialisation you can do to it to make it faster given the constraints of it's current use.. Plus each rewrite of something is always better than the last anyway

I spend all my time rewriting the code that I already have, compiling it (with CC65) and then seeing if I can make it a bit smaller or a bit quicker. I spend so much time doing this, I forget to add new features to my game.

 

How's the train code working? Are they following a list of X,Y coordinates? Or maybe X/Y delta values?

 

Have you thought yet how the "train" method of motion will work in the Challenge scenes inbetween levels where the sprites all overlap? I don't envy you with that bit of code, trying to stop it flickering! (unless you only paint the one at the front).

Edited December 29, 2009 by snicklin

[andym00]

Well, your attention to detail is the thing that will make it a great version of the game - I had a look at the PC Engine version, and if you made a version with no background at all it would still be amazing.

I hope so, if I've got any hair left by the time I've finished

I want to roll the original Galaga into this as well, since it'll just fall out of the code anyway from an engine point of view but the backgrounds aren't really going to be responsible for much pain in the grand scheme of things

( I keep wondering what the XL would have been like if it had been designed with Beeb style components ... more bandwidth, 160 pixel GTIA modes )

 

 

You'll be summoning the witch burners with talk like that

But the Beeb was nice, just a shame I never appreciated it at the time for what it was..

But the XL ? Hmmm, who knows what could have been.. All I can imagine is that the other thread would now be about 160pixel GTIA modes versus Amiga HAM mode

 

 

[andym00]

I spend all my time rewriting the code that I already have, compiling it (with CC65) and then seeing if I can make it a bit smaller or a bit quicker. I spend so much time doing this, I forget to add new features to my game.

 

How's the train code working? Are they following a list of X,Y coordinates? Or maybe X/Y delta values?

 

Have you thought yet how the "train" method of motion will work in the Challenge scenes inbetween levels where the sprites all overlap? I don't envy you with that bit of code, trying to stop it flickering! (unless you only paint the one at the front).

 

I've just got them following sequenced angles for now, just to get it up and running, which also forms the basis for the rest of the code, in that they all drive themselves using a direction and speed, since it made the code nice and uniform for now..

In the Galactic Dancing, they'll use the same stuff, and they'll all be drawn every frame, and if there's flickers using the original data then I'll redo it by as little as possible to fix the flicker, though there's a few were it's not doing to save me at all when they all sit on top of one another like you mention, and that's the biggest worry since the player underlays will be totally hidden and it's likely going to like rubbish, unless the top one is designed so that it doesn't need to use a player underlay.. But I've not got that far to worry about it yet, and if the Galactic Dancing part of the code needs an entirely different renderer, then so be it.. There's always a solution

 

To be perfectly honest, my biggest worry is getting the explosions on the screen, not the galactic dancing ones, but the regular in game ones.. I've still not got a real solution formed in my head yet for those, but I'm sure one will come in time..

 

I've not gone poking through any code yet to see how it's done in the PCE engine version, but I will when the time comes to get the patterns out properly, and will likely grab it from the PCE version simply because I trust its authenticity to the arcade..

[snicklin]

To be perfectly honest, my biggest worry is getting the explosions on the screen, not the galactic dancing ones, but the regular in game ones.. I've still not got a real solution formed in my head yet for those, but I'm sure one will come in time..

 

I've not gone poking through any code yet to see how it's done in the PCE engine version, but I will when the time comes to get the patterns out properly, and will likely grab it from the PCE version simply because I trust its authenticity to the arcade..

 

I think that you have two choices with the explosions and this links into what Heaven/TQA has been saying:

1) Come out of character mode and draw the pixels

2) Stay in character mode and have pre-calculated explosions, though these will eat into your 128 chars per font.

 

If you do it in a char mode, you'll have the issue of having to calculate which chars will be affected, i.e. Not those which already have an alien in.

 

Thinking outside of the box, would you be prepared to accept doing implosions instead? They'd use up less characters.

Edited December 29, 2009 by snicklin

[andym00]

I think that you have two choices with the explosions and this links into what Heaven/TQA has been saying:

1) Come out of character mode and draw the pixels

2) Stay in character mode and have pre-calculated explosions, though these will eat into your 128 chars per font.

 

If you do it in a char mode, you'll have the issue of having to calculate which chars will be affected, i.e. Not those which already have an alien in.

 

Thinking outside of the box, would you be prepared to accept doing implosions instead? They'd use up less characters.

 

Actually the solution just popped into my head anyway reading your post I don't know why I didn't think of it before!!

 

Yup, granted in bitmap mode the explosions are far far easier to handle, but in character mode they don't need to be updated as fast since I'm redrawing (sort of) the entire formation anyway, so the lack lustre frame rate of the formation would mask the even lower explosion animation rate, and adding those on top of the freshly plotted formation wouldn't cost so much, because 90% of the time the character cell it needs to fetch is going to be over an already allocated character for a formation sprite, so only needs to be or'd in where it affects anything, and on those cells not allocated and are background graphics, it'll just have to do the normal copy of the character over (for however many are affected by the explosion), so just 8 bytes to copy for each char then or in the explosion bytes, most of which are empty anyway, and then they'll sit nicely on top, as well as not costing much to render in the grand scheme of things..

 

That'll work well, and since it's bound to the formation rendering which is seperate from the main sprite rendering it'll never look out of sync, positionally.. Just a question if the frame rate for the formation rendering is fast enough for the explosions to look right, but I think it might be but I'll need to go examine them frame by frame to check..

 

And it would work just as well in bitmap mode and char mode so that's one more weapon for the arsenal if I ever change back to bitmap mode..

 

 

Now that's a pleasant solution to a problem that had been niggling away at me for some time

Edited December 29, 2009 by andym00

[snicklin]

Andym00, it's always nice to find a nice pleasant solution like that!

 

I'm going to estimate that you'll need around 4 frames of animation for an explosion to look alright. And if you can get those done in around a second, that'll look good.

 

Now, can the redraw of your formation be done 4 times per second?

 

One thing you'll need to consider is that if you have only a few aliens left, will your formation drawing speed up? If so, you'll need to limit it so that explosions do not finish before you've seen them start!

 

Anyway, it's bed time for me now!

[andym00]

Andym00, it's always nice to find a nice pleasant solution like that!

 

I'm going to estimate that you'll need around 4 frames of animation for an explosion to look alright. And if you can get those done in around a second, that'll look good.

 

Now, can the redraw of your formation be done 4 times per second?

 

One thing you'll need to consider is that if you have only a few aliens left, will your formation drawing speed up? If so, you'll need to limit it so that explosions do not finish before you've seen them start!

 

Anyway, it's bed time for me now!

 

 

The swapping rate for the formation buffers isn't an issue, it'll be (well I'm aiming for) swapping every ~5 frames.. That's the target anyway.. So it'll be redrawing close to 10 times per second, which hopefully will be enough to keep the animation of the explosions looking good, and anything else I might now choose to render using that method.. And it'll be clamped to that, even with less being drawn..

 

As for frame counts for them, whatever the PCE version has I'll have too, though I will check the Arcade version as well..

Edited December 29, 2009 by andym00

[Shawn Jefferson]

Bank switching - never used it so I cannot comment. I've only ever possessed 64K machines. Any game that I write (released 1 in the past and am working on 1 now) will have to fit into 64K, even if my development is on the PC. If I worked on cartridge based development, I guess I'll have to move away from the PC.

 

You can develop for cartridges on the PC as well, most (probably all) emulators will emulate almost all the cartridge formats out there. Cartridges on the A8 are pretty straight-forward. There are two bank 8k windows at $9000 and $A000, and the different cartridges use these in different ways. Some bank both in as one block, some can bank them in seperately, some can bank in one and the other is static, and some only bank in one of the cartridge areas (the AtariMax Flashcart for instance), also some cartridge designs can completely turn off the cartridge as well.

 

A cartridge target will give you the most compatibility with machines out there, IMO. The drawback being that there will probably have to be a physical release (although with the Atarimax Flashcart you can release the binary and owners of flashcarts could just flash your game onto their cart as they please.)

[snicklin]

The swapping rate for the formation buffers isn't an issue, it'll be (well I'm aiming for) swapping every ~5 frames.. That's the target anyway.. So it'll be redrawing close to 10 times per second, which hopefully will be enough to keep the animation of the explosions looking good, and anything else I might now choose to render using that method.. And it'll be clamped to that, even with less being drawn..

 

As for frame counts for them, whatever the PCE version has I'll have too, though I will check the Arcade version as well..

 

10 updates per second sounds enough for me for a nice fluid animation. All this talk of Galaga '88 makes me keep going back for "just another game". It has to be the most complete arcade game that I've ever known. It's a little difficult later on, but apart from that, it's perfection.

 

So you're from an English cowfield Andym00? Any particular ones?

[snicklin]

Bank switching - never used it so I cannot comment. I've only ever possessed 64K machines. Any game that I write (released 1 in the past and am working on 1 now) will have to fit into 64K, even if my development is on the PC. If I worked on cartridge based development, I guess I'll have to move away from the PC.

 

You can develop for cartridges on the PC as well, most (probably all) emulators will emulate almost all the cartridge formats out there. Cartridges on the A8 are pretty straight-forward. There are two bank 8k windows at $9000 and $A000, and the different cartridges use these in different ways. Some bank both in as one block, some can bank them in seperately, some can bank in one and the other is static, and some only bank in one of the cartridge areas (the AtariMax Flashcart for instance), also some cartridge designs can completely turn off the cartridge as well.

 

A cartridge target will give you the most compatibility with machines out there, IMO. The drawback being that there will probably have to be a physical release (although with the Atarimax Flashcart you can release the binary and owners of flashcarts could just flash your game onto their cart as they please.)

 

That's good to know Shawn, thanks. Though I still have to fill up my first 64K first! I've been working hard on keeping file size and memory usage as low as possible with my current program.

[Sheddy]

And also the lack of the 15K timer matching the scanline timing on NTSC makes for a major pain in the butt..

Could be wrong, but AFAIK it should match. CPU clock is 114 cycles per line on both PAL & NTSC and 15Hz timer is derived from that?

 

Really looking forward to this. One of my absolute favourites on PC Engine (Gunhed next maybe ) Sounds like you have loads of really interesting implementation ideas to pick and choose from to make this a reality. This should be a real technical tour-de-force if you can pull it off completely. Wish you well on your endeavour! Even if it can't match the best ones on C64, the A8 is definitely lacking in sophisticated scrolling shoot-em-ups and needs more!

[andym00]

Could be wrong, but AFAIK it should match. CPU clock is 114 cycles per line on both PAL & NTSC and 15Hz timer is derived from that?

 

Really looking forward to this. One of my absolute favourites on PC Engine (Gunhed next maybe ) Sounds like you have loads of really interesting implementation ideas to pick and choose from to make this a reality. This should be a real technical tour-de-force if you can pull it off completely. Wish you well on your endeavour! Even if it can't match the best ones on C64, the A8 is definitely lacking in sophisticated scrolling shoot-em-ups and needs more!

 

All I've witnessed in the few times I've played about in NTSC mode is that everything came crashing down with interrupts going completely haywire when I'm using the timer like this in NTSC mode, I'd just assumed the timing was different and had just written it off as being just down to the different timing, but perhaps I should investigate more then, since so far I've just no bothered to even really look at those issues with NTSC..

 

Actually I'll do that sometime today and finally find out, but I'd forgotten that the scanline timing is the same on the A8s, unlike a certain other machine, so it should just work I guess..

 

So it probably is my fault after all

[andym00]

10 updates per second sounds enough for me for a nice fluid animation. All this talk of Galaga '88 makes me keep going back for "just another game". It has to be the most complete arcade game that I've ever known. It's a little difficult later on, but apart from that, it's perfection.

 

So you're from an English cowfield Andym00? Any particular ones?

 

 

 

No particular cowfield as such, but freshly returned from the lovely green and schnapps and schnitzel laden Viennese cowfields, and back into the dirty smokey and expensive cowfields of London

The family cowfield is not far from you actually.. Lubbenham, near Market Harborough, proper cowfield territory that is

Edited December 30, 2009 by andym00

[PeteD]

Could be wrong, but AFAIK it should match. CPU clock is 114 cycles per line on both PAL & NTSC and 15Hz timer is derived from that?

 

Really looking forward to this. One of my absolute favourites on PC Engine (Gunhed next maybe ) Sounds like you have loads of really interesting implementation ideas to pick and choose from to make this a reality. This should be a real technical tour-de-force if you can pull it off completely. Wish you well on your endeavour! Even if it can't match the best ones on C64, the A8 is definitely lacking in sophisticated scrolling shoot-em-ups and needs more!

 

All I've witnessed in the few times I've played about in NTSC mode is that everything came crashing down with interrupts going completely haywire when I'm using the timer like this in NTSC mode, I'd just assumed the timing was different and had just written it off as being just down to the different timing, but perhaps I should investigate more then, since so far I've just no bothered to even really look at those issues with NTSC..

 

Actually I'll do that sometime today and finally find out, but I'd forgotten that the scanline timing is the same on the A8s, unlike a certain other machine, so it should just work I guess..

 

So it probably is my fault after all

 

You did handle the fact that the vblank has a different number of lines on pal/ntsc?

 

 

Pete

[snicklin]

No particular cowfield as such, but freshly returned from the lovely green and schnapps and schnitzel laden Viennese cowfields, and back into the dirty smokey and expensive cowfields of London

The family cowfield is not far from you actually.. Lubbenham, near Market Harborough, proper cowfield territory that is

Surely the Viennese cowfields were expensive too with the Euro/Pound as they are? Austria is a lovely country though, much like Heaven/TQA's German (Schwabisch) area which I used to live in. Market Harborough, not too far away no.

[andym00]

No particular cowfield as such, but freshly returned from the lovely green and schnapps and schnitzel laden Viennese cowfields, and back into the dirty smokey and expensive cowfields of London

The family cowfield is not far from you actually.. Lubbenham, near Market Harborough, proper cowfield territory that is

Surely the Viennese cowfields were expensive too with the Euro/Pound as they are? Austria is a lovely country though, much like Heaven/TQA's German (Schwabisch) area which I used to live in. Market Harborough, not too far away no.

 

Actually surprisingly not so expensive living in Vienna.. When I went there 5 years ago, what was a pound in England usually translated to a Euro in Vienna.. I mean for eating, drinking, smoking etc.. Housing was much cheaper, travel costs much cheaper, and public transport that actually works bloody well.. Taxes are a bit bonkers, but you get a much better system for it I think, offset by the cheaper costs and a better infrastructure..

Prices did creep up over the time I was there, but that's life I guess, and now back in doomed England things do seem actually quite cheap, in the supermarkets and shops at least, but everything else is still monumentally expensive here, especially in the housing department.. I still miss paying 3 Euros for a beer, 4 Euros for a pack of cigarettes, and 50 Euros for a monthly travel card for public transport..

But being back in London now it soon became clear just how I'd totally forgotten how insanely expensive it is, and wonder how most people can even afford to live here.. But I did miss the dirty old place though.. More than I realised actually

But Austria and Austrians themselves are awesome, with a culture and an attitude to life that is quite enviable in many ways

[andym00]

You did handle the fact that the vblank has a different number of lines on pal/ntsc?

 

Erm It would appear it was something that simple actually

I'd covered NTSC/PAL differences everywhere except in one place (I could have sworn I did though), where I setup the initial wait from the VBL to the early IRQ 4 lines or so above the first line visible line of the displayed screen, so it was halfway down the screen before it synced itself up, ensuring total interrupt carnage and chaos ensued

 

Oops...

[Rybags]

To clarify... with Timers based on the "16 KHz clock", the base unit will be 1 scanline regardless of NTSC/PAL.

 

The VBlank thing... Timers triggered by VBlank would need adjusting for either system.

The VBlank NMI occurs on the same VCOUNT line, but VCount works such that PAL and NTSC will see it as the same from value 0 up to 125 (dec).

Then you have NTSC VSync straight after that and VCount wraps back to zero after reaching 130.

On PAL, VSync occurs after value 137 and VCount wraps back to zero after reaching 155.

 

If you're using a 16 KHz Timer for screen-based events then possibly the easiest solution is to just use a DLI to set them up instead, right at the top of the screen. Then, no adjustment would be necessary for PAL/NTSC.

 

Additional to that, an 8-bit counter triggered during VBlank wouldn't be able to cover the entire subsequent frame anyway, where one triggered from an early DLI will.

Edited December 30, 2009 by Rybags

[Heaven/TQA]

No particular cowfield as such, but freshly returned from the lovely green and schnapps and schnitzel laden Viennese cowfields, and back into the dirty smokey and expensive cowfields of London

The family cowfield is not far from you actually.. Lubbenham, near Market Harborough, proper cowfield territory that is

Surely the Viennese cowfields were expensive too with the Euro/Pound as they are? Austria is a lovely country though, much like Heaven/TQA's German (Schwabisch) area which I used to live in. Market Harborough, not too far away no.

 

Actually surprisingly not so expensive living in Vienna.. When I went there 5 years ago, what was a pound in England usually translated to a Euro in Vienna.. I mean for eating, drinking, smoking etc.. Housing was much cheaper, travel costs much cheaper, and public transport that actually works bloody well.. Taxes are a bit bonkers, but you get a much better system for it I think, offset by the cheaper costs and a better infrastructure..

Prices did creep up over the time I was there, but that's life I guess, and now back in doomed England things do seem actually quite cheap, in the supermarkets and shops at least, but everything else is still monumentally expensive here, especially in the housing department.. I still miss paying 3 Euros for a beer, 4 Euros for a pack of cigarettes, and 50 Euros for a monthly travel card for public transport..

But being back in London now it soon became clear just how I'd totally forgotten how insanely expensive it is, and wonder how most people can even afford to live here.. But I did miss the dirty old place though.. More than I realised actually

But Austria and Austrians themselves are awesome, with a culture and an attitude to life that is quite enviable in many ways

 

London IS expensive... even with CITY going down (but bonus' again paid...so should be better soon... )...how does Queensryche sing in Operation Mindcrime... "the banks stay fat and the poor stay poor and the rich get rich, the cops get paid, to look away...".... ok...another story... living costs in London are really high but not much higher than f.e. in Munich or Stuttgart or Hamburg when looking on the european chart of most expensive cities...

 

When living outside of London you have to take the damned 2 hours public transportation time while on the go... for each direction... no wonder why you are getting drunk each time you have access to alcohol...