ABBUC Software Competition 2017

[freetz]

The games will be available for members at http://asc.abbuc.deas well. The username and password are generated from your membership number and address. It's all explained on the website, but Andreas still needs a bit of time to compile the disks, so please be a little more patient...

[darwinmac]

I am also a US ABBUC member. Since the deadline has just passed, I am assuming the ATR images have not been made yet so they can be downloaded from the ABBUC website. I am hoping an announcement will be made in this thread when they are available to be downloaded.

 

Bob C

[+CharlieChaplin]

Hmm,

 

the disks are almost ready. Will do a final test tomorrow. Translated one german text into english and converted this and all other texts to 38 chars per line ATASCII, so they are readable from the Abbuc menu. So, the (disk-) magazine will contain the games + english manuals/texts, whereas the paper-magazine will most likely include the german manuals/texts...

 

Had to pack two games (Citron3kg and NewAtariGame, compressed to less than half of the original size), otherwise three disksides would be required and with packing these two games, everything fits on two disksides. Remember: Wolfgang has to make more than 400 copies of these disks...

 

Several games (e.g. Bomb Square Duel, SuperflyXL Lite, etc.) require a DOS, all games work fine from the Abbuc menu (which runs under DOS 2.5), one game (SuperflyXL Lite) uses data $B800-BFFF so you will see a little garbage while loading for a short time (but nothing to worry about). Added the usual Basic-off routine to all ML-files (including the CTB-Runtime), so there is no need to hold down the Option key when loading them. Added also a Reset=Reboot routine (equal to Poke 580,1 in Basic), so all ML-Games will do a coldstart / reboot when Reset has been pressed, thus no need to power-off + back on your real Atari computer...

[+CharlieChaplin]

Alright,

 

after all ASC 2017 programs have been tested on an unmodified 64k PAL 800XL computer (executed from the Abbuc diskmenu) and worked fine there, I created the disk-images and did send them to freetz today who will upload them on the ASC webpage soon...

[freetz]

Thanks, Andreas. I'll upload them once Wolfgang has done the final processing (i.e. proper menus etc.) "Half-baked" stuff doesn't make anyone happy ...

[8Bitjunkie]

Could be interresting to see. Do people vote for non Atari Hardware, just because people write software for that, or does justice correct itself by losing any interrest by the community, because most Atari owner cannot run that software on a real machine.

 

It is really ridiculous, to see "non Atari" Hardware arriving the ABBUC SC , but people still blaming software that is running on a real Atari, using ALL features incl. undocumented opcodes of the CPU ...

 

yeah, the grumbling squirrel is complaining again. Must be contest time again

 

Still waiting for your submission, btw...

Edited August 5, 2017 by 8Bitjunkie

[VladR]

- The limitation to a stock 800 XL has been waived. You can now submit software that can make use of any extension available - but bear in mind that the more detailed your hardware requirements are, the less likely it is that the majority can run it and award points accordingly. So in case of very special requirements, you'd have to make sure that your game/application really rocks ... The rationale behind this is that this should encourage authors to support a greater variety of extensions, such as MultiJoy or VBXE.

1. I presume that for 2018, this limitation will be the waived the same way ? Thus it'd be safe to start slowly working on something (for 2018) now, that targets more RAM ?

2. What is the "safe", yet still widespread RAM extension that is safe to target ? Is 512 KB too rare ? No idea on the % of distribution of various RAM upgrades. It's quite fragmented, from what I've seen so far.

Targeting 256 KB, while 4x as much as stock 800XL does not make much sense to me, as it's just double what stock 130XE has. Doubling that to 512 KB does open up a lot of other and new possibilities, though!

[freetz]

I would assume the rules stay as they are unless the JHV votes otherwise (and then also a new organizer of the contest), so you'll know for certain at the end of October.

And in the end, it depends on the individual member - for example, I only have an Atari with "just" 320k, but rather than downvoting a game just because I don't have the hardware, I would try it out on an emulator to evaluate its quality. But then there are the purists who might downvote such a game because it doesn't run on their or even a stock 800 XL. Which faction has the bigger impact is hard to tell because this year, none of the games that have been submitted made use of additional hardware. So we'll have to see what 2018 brings...

[emkay]

yeah, the grumbling squirrel is complaining again. Must be contest time again

LOL

 

You missed the point

 

No need for grumbling ... this time....

 

It's just that the poor little ATARI still misses that "mind blowing edge pushing" community. You know, it's now 40 Years....

 

Just an example: POKEY is only able to play "square waves" ,only can do 4 bit volume steps.... neither it can play a high range of melodic parts...

 

 

So I'm just listen to my experiments, wondering why all of my projects get killed... You know of "Super Fly" ? Not that one of this contest

Still waiting for your submission, btw...

Sry, but You can wait for "my submission" after the whole community did a 180 degree turn Edited August 6, 2017 by emkay

[8Bitjunkie]

So I'm just listen to my experiments, wondering why all of my projects get killed...

 

So, i've just listend to your experiments, not wondering why all of your projects get killed...

 

 

... after the whole community did a 180 degree turn

 

... so they can see you again?!?

 

Sorry, but you demand commitment to push the Atari to the edge,

but bringing nothing of value to the community by yourself.

That does not fit, my dear grumbling squirrel...

 

Have a nice life, go out, find some friends...

 

 

 

 

 

 

[VladR]

I would assume the rules stay as they are unless the JHV votes otherwise (and then also a new organizer of the contest), so you'll know for certain at the end of October.

And in the end, it depends on the individual member - for example, I only have an Atari with "just" 320k, but rather than downvoting a game just because I don't have the hardware, I would try it out on an emulator to evaluate its quality. But then there are the purists who might downvote such a game because it doesn't run on their or even a stock 800 XL. Which faction has the bigger impact is hard to tell because this year, none of the games that have been submitted made use of additional hardware. So we'll have to see what 2018 brings...

1. Do the current emulators support paging in data from, say, 512+ KB ?

2. Can you submit multiple different-sized builds ? Say, via #ifdef blocks, remove blocks of game, and keep just the core game for 64 KB, but enhanced (e.g. more game screens / levels) for 512 KB ? it's more work and testing, but if designed right, from the very start, especially with automated unit testing in Visual Studio (with running the translator to 6502 ASM only as a last pass), it is very doable.

 

I'm asking, since until now I never considered this contest, as I had my fun with A800XL's 64 KB of RAM quarter century ago, and was each year waiting, if this limitation is going to be revisited (given how long all these memory expansions have been around).

 

Which, finally, happened.

[Mathy]

Hello VladR

 

Please just write your software as you like it. Stuff like separate or non-separate ANTIC and CPU access (forget about CharlieChaplin's respond that will follow), which bits are used and how, etc. can all be tested. What we need is software that needs all these RAM-extentions or that at least can use these RAM-extentions. We've been waiting way to long for this.

 

Sincerely

 

Mathy

 

[VladR]

Hello VladR

 

Please just write your software as you like it. Stuff like separate or non-separate ANTIC and CPU access (forget about CharlieChaplin's respond that will follow), which bits are used and how, etc. can all be tested. What we need is software that needs all these RAM-extentions or that at least can use these RAM-extentions. We've been waiting way to long for this.

 

Sincerely

 

Mathy

Thanks, that would be lovely, but examining the ABBUC rules, it looks like the physical build is still limited to about 256 KB - e.g. 2 floppies (e.g. 2x 130 KB = 260 KB). Here's the quote from ABBUC rules pdf:

 

2.1.3 submitted on a maximum of two unprotected 90KB or 130 KB 5.25 “ floppy disk sides or ATR - Images). The authors are allowed to provide further disk images for download under the condition that the images are not able to run standalone,e.g. level disks

I haven't seen the submission web, but I interpret this as 260 KB is max you can upload as an entry, but you can have something like optional DLC via downloadable images. So, the game still must run off those ~256 KB, even if you - hypothetically- required 1 MB extension.

 

I suspect at run-time I could require those 512+ KB (say, for run-time generated data), but the primary build / content looks it has to fit under 260 KB.

 

Assuming I'm interpreting this right...

 

 

Do at least 10% of active atarians have a memory extension ? Those memory board production numbers, from what I've seen, run in very small numbers (understandably, as it's hand-built, in free time).

[Heaven/TQA]

I think 320k is more than 10%... I don't know any atarian except Popmilo who have only a 64k machine .

 

And think of packing and procedual gfx/maps using those extra ram (7 cities of gold map in ram?) and you have 260k for code etc (2 disk images) is a LOT.

[Heaven/TQA]

256kb ram was "standard" expansion back in those days. What you see here are the "new" upgrades... like the 320k cart which I adore... it was made perfect for me... plug and play no wiring.

[emkay]

So, i've just listend to your experiments, not wondering why all of your projects get killed...

Most coders on the Atari were no musicians. So I understand your point.

[freetz]

@VladR:

1. I know that Altirra supports up to 1MB memory extension, but don't ask me about specific details regarding implementation.

2. You can sumit a game that supports various kinds of extensions, but only one submission per game is possible. So the #ifdefs would have to be done in the Atari Code, not in the IDE you're using.

 

And yes, the limitation of two disk sides might appear to contradict the possibility to use more than 256kB of RAM. That's why we allowed users to provide additional disk images via download. Anything else would just not be feasible as long as every contribution will have to be distributed on real floppies (which I support and thus this limitation will most likely stay), and we cannot expect Wolfgang to copy more than half a dozen disks just for _one_ contribution. And, as Heaven/TQA said, 260kB of code is a lot already.

[matosimi]

@VladR: I think you are too greedy about the amount of RAM.

You can build some game that uses ram extensions, but still 64kB is the most usual setup for most of Atari XL/XE users.

 

Also I have no idea of what your intended game should be, but you can create 2 versions... one for HW with extensions and one for classic 64kB XL/XE... it depends on the actual game progress... but you can either use additional disks (which I do not prefer) or you can build binary out of data and init blocks and load the data as player progresses through the game... how I did it in case of RR which is playable on classic 64kB Atari, even the binary has 76kB and it contains more than 200kB of uncompressed data.

 

I will be happy to see a nice new game that will bring lots of fun... however I'm a bit skeptical.

 

I suggest to create POC for stock 64kB Atari and then you can decide how to enrich it with additional levels/gfx/msx... it is usually not a big deal to implement bank switching or additional loading.

[+therealbountybob]

...

4. When I logon to the abbuc forum it still shows "Not Logged In" on the top right banner but it does change to another page. My username on there was "gwobby" . I'm sure I've had this before and I've just reset my password and it's the same?

 

 

4. not a bug, but a pgming feature: a) goto the Abbuc startpage, b) on the top right click on "not logged in", c) a new page appears - login here d) when done visit the abbuc forum (it should now show "logged in as...")

 

If you login from another page than the Abbuc startpage, then login does not work... (strange because other subpages also have a login button, you can even login there, but the forum and some pages still show NOT logged-in... afaik this has to do with different programming languages used on these pages e.g. php versus joomla versus ...)

......

 

This still doesn't work - still shows "not logged in" on top right.

 

Also I want to renew my subscription can I paypal someone from abbuc please?

[VladR]

I think 320k is more than 10%... I don't know any atarian except Popmilo who have only a 64k machine .

 

And think of packing and procedual gfx/maps using those extra ram (7 cities of gold map in ram?) and you have 260k for code etc (2 disk images) is a LOT.

I must say, I was hoping for a higher penetration number, (I just randomly chose that 10% number), but thanks for the reality check.

 

@VladR:

1. I know that Altirra supports up to 1MB memory extension, but don't ask me about specific details regarding implementation.

2. You can sumit a game that supports various kinds of extensions, but only one submission per game is possible. So the #ifdefs would have to be done in the Atari Code, not in the IDE you're using.

 

And yes, the limitation of two disk sides might appear to contradict the possibility to use more than 256kB of RAM. That's why we allowed users to provide additional disk images via download. Anything else would just not be feasible as long as every contribution will have to be distributed on real floppies (which I support and thus this limitation will most likely stay), and we cannot expect Wolfgang to copy more than half a dozen disks just for _one_ contribution. And, as Heaven/TQA said, 260kB of code is a lot already.

Thanks for clearing it up. I totally missed that physical distribution part (manual work+shipping+etc.) !

 

Any chance for an unlimited / download-only category, in future - even without a monetary prize ?

 

 

And, as Heaven/TQA said, 260kB of code is a lot already.

The moment you start unrolling the bitmap drawing loops (separate per each bitmap), the memory consumption of code shoots exponentially up to the sky. And that's just one application. One could argue that a self-modifying code could prepare such a code on demand, but I'd rather focus on adding more gameplay than these demo tricks.

 

260 KB severely limits number of bitmaps I can include. At 160x192x4, each one takes 7.5 KB (about 26 would fit). Just the 2D terrain map I was considering takes up 128 KB in itself.

 

These days, the content / renders is very easy to create with tools like 3dsmax and WorldMachine (few clicks, and boom, you got 4 GB of unique terrain data).

 

One idea I just got is that for example for a 2D terrain, a contest build would contain only 3x3 (=9) screens, but a DLC could have ,say, 8x8 (=64) screens. For engine it does not really matter (how many are on disk), as it only swaps in one screen at a time anyway. Gameplay impact will be obviously much shorter gameplay (as you find stuff much faster in smaller area).

 

 

I'll keep butchering the design further.

[freetz]

Hm, I could suggest such a "unlimited" category at the JHV, but I'm not sure whether people would contribute if there is no prize, compared to aiming for a prize when they stick to two disks. On the other hand, such a large game would result in serious disk swapping anyways. But if you said you could do such a game with a smaller world with 260kB, why not implement this as the "basic" version and provide additional downloads for a "larger" version? That would enable you to participate in the contest and also win a prize if you get enough votes.

[VladR]

And think of packing and procedual gfx/maps using those extra ram (7 cities of gold map in ram?) and you have 260k for code etc (2 disk images) is a LOT.

Compression, unless it's JPG, artifacts of which look awful in low resolution and colors, never really brings much. How much more % of image data is realistic on Atari from your experience ?

 

As for procedural content creation - I'm a huuuge fan. I spent lots of effort in past on procedural content generation.

 

But on 1.79 Mhz Atari ? We gonna let players stare at loading screen for 3-5 minutes till it generates the terrain via fault lines ? And that's assuming 1.79 MHz could even do that in 5 minutes, which I really doubt.

 

Plus, generating all that content on PC takes less than an afternoon of clicking. How much risk is it to start implementing something like that on Atari and never finishing it ? Though, for something like this, I would go for C compiler, for sure.

 

I'm going to prototype on PC first anyway, then slowly start porting C code to using 3 registers (X,Y,Accumulator), which then should be easy to port to 6502 ASM (for rendering functionality).

[Heaven/TQA]

Well...

 

You don't want to not pack your data?

 

Have a look at the voxel map of arsantica 3 that is 16k if I remember it right (64x64)

 

Check planet5200 on 5200 that has procedual generated texture and map... doesn't need so much time.

 

Have a look at arsantica 2... there i have packed huge unrolled code and texture for the texture shaded planet spread over banks...

 

Loading times? Suck....

[+CharlieChaplin]

Well,

 

Exomizer and Inflate is your friend !

When GTIA Blast was released as a playable demo it had an unpacked length of more than 400kybtes, I could pack it to less than 120kybtes; the final version was released as Atari Blast which requires a) an 8Mbit (1MB) atarimax cart. or b) 1MB of eXtended RAM, thanks to Exomizer or Inflate this XRAM version fits on two 180k disks or one 360k disk.

 

So, if you have two disks available with 130k each (260k total) for the Abbuc contest you can fill them with up to 520k data when using a good packer/compressor for that data... but the Atarians with highspeed SIO-loaders, cartridge XEX-loaders or harddisk XEX-loaders have to wait quite some time for depacking then (so you have to offer them the unpacked version too).

 

Of course you can also invent a MP4 cart. for the Abbuc hardware contest and then use this cart. to load and depack your mpeg-4-compressed (16MB XRAM sized) game from the 130k diskette...

Edited August 7, 2017 by CharlieChaplin

[+CharlieChaplin]

 

 

 

This still doesn't work - still shows "not logged in" on top right.

 

Also I want to renew my subscription can I paypal someone from abbuc please?

 

Alright then, regarding the login-problem, contact an Abbuc admin...

(e.g. int€rn€t@abbuc.d€)

 

You can paypal me if you like, but then I need your real name, postal adress and member-number (e.g. with a p.m.) to forward it to Abbuc/Wolfgang (not sure if he is happy when I send money via bank transfer to pay someone else's membership)...