What made crownland so colorful?

[popmilo]

Thanks for explanation and code Paul ! You guys did awesome work with Gtiablast !

 

Two scanlines 'head start' is same what I've found out in my pm experiments so far...

Even in Bitmap mode there is very small number of cycles available to cover all possible cases. With 4 sprites in same line and two of them at edges of screen its really tough to change color and hpos for all at once...

Guess we have to stick to what's the 99% type situation and not on those cases that almost never happen...

[snicklin]

I consider Crownland not only to be technically well created, but also I consider it to be artistically well designed.

 

The artwork was done with good consideration to the limitations of the A8 and how to work around them.

[+MrFish]

BTW, speaking of Crownland's pros and cons: I'm seeing random scanline flicker on the upper part of the display -- although not often. I don't remember seeing that on real hardware before, only flickering of sprites where it's supposed to. I don't have real PAL hardware to test it out at the moment. Is that what it's doing on real hardware, as seen in Altirra?

Edited March 11, 2015 by MrFish

[emkay]

IT flickers sometimes without a "need" for showing the PMs.

 

That's why I was thinking of the stars would have been placed better as a char animation. An underlayed player for the golden colour could have been used 2 times , so there should no flickering appear.

[+MrFish]

Good point about using chars for the stars (hey, it even rhymes), since they're stationary. You could probably even get away with no P/M's at all there, having the reds and beige available already.

 

Are we talking about the same flicker though? I'm not talking about P/M flicker here. What I'm seeing is random flickering of entire scanlines, which seems to have no relation to P/M flickering/multiplexing whatsoever.

Edited March 11, 2015 by MrFish

[+playsoft]

BTW, speaking of Crownland's pros and cons: I'm seeing random scanline flicker on the upper part of the display -- although not often. I don't remember seeing that on real hardware before, only flickering of sprites where it's supposed to. I don't have real PAL hardware to test it out at the moment. Is that what it's doing on real hardware, as seen in Altirra?

 

I played it tonight and the scanline glitches appear on real hardware too. They only seem to occur in the clouds and the sky, so are not that noticeable. Not present in the demo version though.

[+MrFish]

I played it tonight and the scanline glitches appear on real hardware too. They only seem to occur in the clouds and the sky, so are not that noticeable. Not present in the demo version though.

 

OK, thanks. I didn't remember seeing them before, but maybe I spent more time playing in Atari800Win PLus, which I don't think shows the glitches -- or at least not as often.

[TheNameOfTheGame]

The flickering always confused me...it seemed to have no bearing on the number of sprites....I thought it was because I was using NTSC hardware.

 

I would purposefully go to a screen where there was only one enemy and no stars. And when I jumped it would still flicker very much. I never understood why.

Edited March 12, 2015 by TheNameOfTheGame

[+MrFish]

Using an NTSC machine is a totally different issue. Crownland is basically not compatible with NTSC, although you can get it to play. The main issues are probably with code in the horizontal and vertical blanks not having enough time available to execute. That'll cause all kinds of weird effects.

[Creature XL]

The flickering always confused me...it seemed to have no bearing on the number of sprites....I thought it was because I was using NTSC hardware.

 

I would purposefully go to a screen where there was only one enemy and no stars. And when I jumped it would still flicker very much. I never understood why.

 

When you jump, more PMG data has to be moved. Maybe the timing of DLIs get distorted.

 

 

@stars as chars:

typical problem in this forum

We all know what the Atari can do, but not everyone excepts that not EVERYTHING goes at the same time.

I would suspect that "Crownland" uses PMG-collisions. The check for collisions only take few cycles.

if you use chars you either have to limit the colors to avoid "collisions" with background OR you have to spend hundreds of cycles to check for collisions.

"Hundreds of cycles" is not much (around 25k per frame are available), BUT with all this DLI trickery to get lots of colors and different scroll speeds cylces get lost.

 

The above is of course just speculation, but the core statement stays: "The A8 can do lots of things but not everything at the same time!"

Edited March 12, 2015 by Creature XL

[TheNameOfTheGame]

Using an NTSC machine is a totally different issue. Crownland is basically not compatible with NTSC, although you can get it to play. The main issues are probably with code in the horizontal and vertical blanks not having enough time available to execute. That'll cause all kinds of weird effects.

 

That's what I thought. It seems tightly programmed for PAL timing.

[emkay]

When you jump, more PMG data has to be moved. Maybe the timing of DLIs get distorted.

 

 

@stars as chars:

typical problem in this forum

We all know what the Atari can do, but not everyone excepts that not EVERYTHING goes at the same time.

I would suspect that "Crownland" uses PMG-collisions. The check for collisions only take few cycles.

if you use chars you either have to limit the colors to avoid "collisions" with background OR you have to spend hundreds of cycles to check for collisions.

Jumping on the playfield is built upon watching the crystal ball ?

 

I guess, the stars had been build with PMg because they sometimes appear in a "parallax layer" . This effect would be distorted then.

And btw. rotating 2 chars instead of doubling two 3 colour-PMs is always using less CPU. Even if you use a Player-square behind the rotating star, to have your collission detected ...

The above is of course just speculation, but the core statement stays: "The A8 can do lots of things but not everything at the same time!"

Exactly my words.

Edited March 12, 2015 by emkay

[+MrFish]

@stars as chars:

typical problem in this forum

We all know what the Atari can do, but not everyone excepts that not EVERYTHING goes at the same time.

I would suspect that "Crownland" uses PMG-collisions. The check for collisions only take few cycles.

if you use chars you either have to limit the colors to avoid "collisions" with background OR you have to spend hundreds of cycles to check for collisions.

"Hundreds of cycles" is not much (around 25k per frame are available), BUT with all this DLI trickery to get lots of colors and different scroll speeds cylces get lost.

 

The above is of course just speculation, but the core statement stays: "The A8 can do lots of things but not everything at the same time!"

 

You're right, I'm just thinking in terms of using a capability here, not how taxed the system might be as a result. However we're not talking about moving stars about the scrolling playfield.

 

 

I guess, the stars had been build with PMg because they sometimes appear in a "parallax layer" .

 

Yes, that would put a limitation on placement.

Edited March 12, 2015 by MrFish

[Creature XL]

Jumping on the playfield is built upon watching the crystal ball ?

 

I guess, the stars had been build with PMg because they sometimes appear in a "parallax layer" . This effect would be distorted then.

And btw. rotating 2 chars instead of doubling two 3 colour-PMs is always using less CPU. Even if you use a Player-square behind the rotating star, to have your collission detected ...

 

 

 

As I don't understand your cryptic comment in the first sentence, I explain what I meant:

 

If the PMG is at the same Y-Position as in teh last frame you do not have to clear the old data. When you jump (move it vertically) then you have to clear a few bytes.

Additionally, you have to fetch data from a "jump LUT" and manage the index into this LUT. This all takes cycle (not much, though)

 

 

@chars: do you know if there are enough chars left?

The "stars in parallax" might be a good reason to use PMG.

[_The Doctor__]

I find crownland terrible since it was never fixed or even took a glance towards working on NTSC, re-ordering the code or taking advantage of the couple of scanlines ntsc doesn't use to make up the difference.... the fact is if a team wishes to they would realize that it all pretty much balances out in the 50/60 front and was done by design. This has been shown to be true and is the reason why there were often two versions put out or a detection was done and modification code executed.... I don't care for 60 hz software that plays too slow or distorted on 50hz and I care even less for 50hz coding that doesn't play at all on 60hz..... and before all the hate starts from both sides of the ponds.... fixing count down timers and the like so levels can be completed and the like isn't anything our super coding maniacs can't do in their sleep.... cramming as much code in before an update is good. but that update is and can be variable to some degree up to the hard limit....so why not adjust around it... the clocks are slightly different for a reason.. and it's not just to make a display problem go away....the unused line time can be used for other things.

I have incredible respect for all people who create on our wonderful machines.... my time to do so may be passing or indeed already has passed... Please allow that I can still impart a modicum of insight here and there as that ability continues to fade away.

so many wonderful works exist and are colorful fluid and fantastic....the constraints make you uniquely qualified to go out into the world and work in fields others would find hard or nearly impossible to work in as they are used to only work in a large seemingly unlimited pool or memory and wasted space. You have the skills and can work on chip/device micro code that others would lose their heads over.... the art of cycle counting......That is why so many had migrated from the vcs and 800 lines to some of the most demanding, challenging, and rewarding careers in the electronic wonders we have today. I am grateful to see old coders come back and the new coders, graphists and musicians coming in.

 

I know that's a bit of a ramble...and perhaps it's out of place.... but it is what it is... I'm off to play a few rounds of Atari Blast as it satisfies me on a large number of levels!

Edited March 10, 2017 by _The Doctor__

[funkheld]

what shoud that ?

Would be nice if you could write, with what was programmed for the atari.

greeting

[+Stephen]

I get quite annoyed at people that complain about PAL software not running on the NTSC machines. It is not always possible. The PAL machines are better at many things than the NTSC machines, and since the Euro folks are doing 90% of the coding these days, why shouldn't they code for THEIR native machines? It's quite easy to have one of each these days, and if not, use an emulator.

 

Would you demand that Japanese or Polish software is written in English? That's just as rude.

[_The Doctor__]

Really? I can google translate just fine and any number of other ways of understanding what is written.... I often just ask someone and they tell me... and the software still runs fine... but make the leap from a simple thing to something akin to being rude anti-multicultural or maybe even racist... I thought better of you than that...

 

No one put down picked on or was derogatory about any spoken language or peoples... don't make it about that!

 

It's simple... heard it a million times.... it's not possible on NTSC and then someone fixes it.... If they don't want to bother then they don't want us to use it.... that's simple as can be.... and since it cuts out half the users of the machine... that might be poor form too....

 

In my humble opinion if it doesn't run on ANY the machines I have then for me it is terrible. I can ask it be fixed or made to work and that's not rude, In fact if I hadn't done this repeatedly there would be far less NTSC software to enjoy because programmers enjoyed the challenge, were nice, and were my friends. They took the time and made it work for us. I even gave English translations for some when the standard online translator borked the meanings.

 

If I have parts for a car or mods for it's control system I don't need it in English like your making it out to be, I just need the car to work or run.... if it doesn't then that's terrible... I have every right to be UN-impressed or not happy about it...

 

I did find someone with a hacked pal machine... the flicker, hitches and glitches still made it terrible.... so moving on.

 

I gave kudos to the better programmers and what fields they go into and are stars in or may be stars because they take the time to do it right and make it work! Very high praise indeed. Maybe you didn't make it that far into the posting?

Edited March 23, 2017 by _The Doctor__

[emkay]

If one wants to do an NTSC Version, he has to cut the CPU usage. Full NTSC using games, keep approx. 20% CPU free on PAL machines. If one uses the available 20% , it cannot fit into an NTSC Machine.

Cutting CPU usage could mean to drop playing music and/or removing several Displaylist lines. Shortening the DL means to have more time for VBI.

[popmilo]

.. If they don't want to bother then they don't want us to use it.... that's simple as can be.... and since it cuts out half the users of the machine... that might be poor form too....

My thoughts are that it's much simpler than "they don't want us to use it...". It's more like coders on this side of ocean aren't even thinking about ntsc. We've grown up with Spectrums, Amstrads and Commodore... Most of us have only found out how big US nerdom fanbase is when we started listening to US podcasts and reading forums about Apple and Atari computers. There's plenty of Poles and Germans on this side of pond and not to mention rest of Europe where everybody uses only PAL and has been using it since they were born...

 

I will try every time to make something work on Ntsc, but it can really be a problem sometimes. Like Emkay said, if game depends on precise frame timing sometimes it's really not possible to squeeze everything into less time available. Anything beyond that requires time and effort to do it by excluding elemnts of game or making it slower.

 

And when you spent months and years trying to make it work in Pal, it's sometimes enough that you have a common cold or wife wants to go to movies and that simple pal->ntsc conversion never happens

[pirx]

I totally support that - it is not like we do not care about NTSC, but we simply had never a chance to try it. 400/800 machines were nonexistent here and it all started when Tramiel dumped dirt cheap 800XLs to the market ($115 when my mum's salary was ~$25 per month at this time, so cheap it was only relatively : ).

 

Additionally many of us came from demoscene and Crownland is a perfect exaple of a game made by sceners for sceners where the tight timing and show-off is more important than longewity and reaching broad audience. It has been released at Abbuc meeting and that is, story is over.

[Kyle22]

When I receive my new CPU card I hope to be able to run Crownland.

 

[+MrFish]

I find crownland terrible since it was never fixed or even took a glance towards working on NTSC, re-ordering the code or taking advantage of the couple of scanlines ntsc doesn't use to make up the difference....

 

A few other things to keep in mind here regarding this issue...

 

Since Crownland was done for the ABBUC contest, which is on a strict time constraint, I have a feeling there was no time left to adjust anything. In fact, even if there was enough time, if one is trying to win a contest, the first thing to pay attention to is how good the game itself is (graphics, playability, music, etc.). So any extra time would always go into those things first.

 

Secondly, well, Crownland lost -- or maybe better to say, "was shown up". So here we have a team that is surely big-time disappointed by the results when they obviously put A LOT of hard work into the production, and most likely in a lot less time than one would choose for such an involved piece of work. Then, we had some "disappointment tantrums" by people who thought Crownland was going to be the Atari's "answer" to Super Mario Bros. It wasn't, but it was obviously a landmark achievement on the system, and certainly deserved no bashing for the effort. And finally, there were the criticisms of the sprite engine and choice of narrow-screen mode. So after all that, how motivated does anyone think the team might have been to entertain requests for an NTSC version, improvements, or anything else related to the game for that matter?

[emkay]

The demoversion Crownland was better than the game itself. That was one mistake. Then there was the rule, the game has to fit into 64K machines and have to run from a compatible device "1050 for example" . They might have understood it wrong and shrinked the game to fit into one Disk side.

[+MrFish]

The demoversion Crownland was better than the game itself. That was one mistake.

 

I think you mean "better" in some ways. It obviously wasn't better to have one level compared to many, less enemies, less bonuses, and death on a single touch.

 

Another thing good about the demo, though, was that it mostly worked on NTSC, which was one reason people were disappointed with the final game.

 

 

Then there was the rule, the game has to fit into 64K machines and have to run from a compatible device "1050 for example" . They might have understood it wrong and shrinked the game to fit into one Disk side.

 

What do you mean about a rule that it has to fit into a "64K machine"? Crownland runs on a 128K machine only, which was the memory limit for the contest.

 

About running from a disk... I wouldn't speculate on something like that. Better to let the developer speak for themselves on what they understood.

Edited April 4, 2017 by MrFish