Why is the homebrew scene on the Amiga not as impressive...

[tomcat666]

Originally Posted by nobody

It is surprising that machines as Spectrum 48k and Amstrad CPC with a z80 at 3 mhz and some KB of memory have a decent game making tool but the Amiga does not. That explains why the Spectrum has so many new games every month.

http://www.randomkak.blogspot.co.uk/...tutorials.html

I would rather have 1 quality game per year than 30 of those made with various "game designers" on speccy. They all look and play the same

[tomcat666]

Originally Posted by Apollo

No offense to the C64 fans, but, the Amiga is a bit more complex on the hardware side, f.e. cpu vs. co-processors.

That is just not true. I did a lot of things on both platforms and actually coding a (quality) game is MUCH easier on an Amiga than on the c64:

- CPU ... 6502 1Mhz and 68000 7Mhz is a HUGE difference. It is much easier to code the engine, the AI, etc. on the Amiga than on the C64.

- Scrolling using a big area and with all colours is VERY tricky to do on c64. You can use VSP but then your game won't work on all c64 versions. You can do nice and fast scrolling but limiting yourself to 4 colours. On Amiga it is VERY easy to scroll the bitmaps around and still have a lot of cpu left over to do all the tricks. And when you see what you can do with the copper and compare that to the Vertical Interrupts on the c64 where on some lines you are left with virtually zero cpu time you know what I am talking about.

- Blitter will help you immensly and basically make BOBs possible. Almost no c64 game uses the "bob" approach, you have to write a sprite multiplexer and mask the sprites, etc. to come anywhere near what you can much easily do on the amiga.

- Memory restrictions. While it is true that the graphics will take more memory on the amiga the actual memory you have for the game engine, precalc tables, AI, etc. is MUCH bigger on the amiga than on the c64.

There are more things of course, but these are the main reasons why game *CODING* is easier on the Amiga than the C64.

However it seems to make quality graphics (and music) is proving next to impossible on the amiga these days. While we get games with graphics which are at least on par with the old days on the c64 (mostly even better) we get really crappy visual experience with new amiga games.

[gazj82]

Originally Posted by tomcat666

I would rather have 1 quality game per year than 30 of those made with various "game designers" on speccy. They all look and play the same

Spectrums AGD is very very versatile and does not tie you to one genre say like the C64 SEUCK. I must admit most people want to make their own Manic Miner type game as per the tutorials posted earlier. But I have made two games with AGD that are far from manic miner platform type.

Three very different games with AGD

Killer Bees - Mine - [ Show youtube player ]
Chopper drop- Paul Jenkinson - [ Show youtube player ]
Terrahawks - Mine - http://www.worldofspectrum.org/forum...rahawks#latest

[nobody]

I dont think AGD games play the same at all

[ Show youtube player ]
[ Show youtube player ]
[ Show youtube player ]

[phx]

Originally Posted by Tsak

- Remakes/sequels/conversions with new or original content: There's plenty of room for originality and a fresh experience to the end player here. This is pretty much the case with the C64 Castlevania remake. It's an easier and safer path to take (compared to developing a completely new game concept from scratch) but we've yet to see such an undertaking done successfully on amiga.

I think that Sqrxz (1, 2, 3) falls in this category. It is an SDL-game written in C for Windows and Linux, which was rewritten in 68000 assembler for the A500.

- Team projects: This seems -unfortunately- NOT to be the norm in our days...
...
The reasons behind those outcomes are many: lack of determination, boredom, real life getting in the way, technical problems, game's scope getting out of hand, disagreements with other members or simply a change in priorities.

Often it is sufficient to kill these projects when only a single team member becomes inactive. So the risk increases with the number of people involved.
As a programmer I must be absolutely sure that I can rely on my team, because I don't want to spend a year of work for nothing. This keeps me away from uncertain "adventures".

- Game concepts begging for support: Every now and then, several game concepts are brought into the public's attention

In most cases you have some game graphics looking for a programmer, but that will hardly ever work. Finding a programmer who likes exactly the concept and game type which is shown is quite unlikely. And even if that would be the case, the graphics are often unusable, because they are drawn without taking the limitation of the hardware in account.
It works best when designing the concept first. The programmer thinks about the technical implementation and defines the constraints for the graphics. Then the artists start drawing.

1) There are dozens of new WIP games that are lurking around in various threads all around EAB. It would help a lot if all those were moved to Game Factory.

Although not everybody wants the public to know about it. But a database about Amiga finished homebrew games could be motivating.

2) A sticky thread or database of people that are willing to work and contribute in game making, their field of expertise or current status would be UBER useful.

Good idea, but I doubt that the information given there is sufficient to select your team (see above).

4) Going crowd funding for an amiga game may sound like a terrible idea but it has some potential.

Depends. With a real job and limited time I wouldn't take the additional pressure imposed by that for no money of the world. Otherwise it might be interesting.

5) Cammy's sticky thread about “amiga game making resources” is a first step towards the right direction. This could be largely expanded to contain not only links to other websites but also tools , examples and various other info regarding amiga game making.

A documentation specifically about Amiga game programming would be nice indeed. I tried to give a bit of help in that direction by releasing the source and all tools of Solid Gold. But a good documentation or tutorial needs a lot of work, probably more than writing the game itself.

Originally Posted by appiah4

I would more than happily code for it as an enthusiast in 2015.. If only I knew what tools to use and where to go for the knowledgebase.

This is great, but do not expect too much from yourself. We have many coders here who know 68000 assembler and every aspect of the Amiga chipset inside out since 25 years or more - and still there are not so many games...
Make sure to keep your first project very, very, very small. A successful mini project gets you the motivation to proceed.

[Apollo]

Originally Posted by tomcat666

That is just not true. I did a lot of things on both platforms and actually coding a (quality) game is MUCH easier on an Amiga than on the c64:

I wouldn't say 'easier', I would prefer saying 'you have more freedom to do things on the amiga'. More on that later.

Originally Posted by tomcat666

- CPU ... 6502 1Mhz and 68000 7Mhz is a HUGE difference. It is much easier to code the engine, the AI, etc. on the Amiga than on the C64.

Again, yes, you have more power to do things. You could even try to implement a "bob" engine only with the CPU (not that this makes much sense). My point is: this freedom comes from the higher complexity _and_ the power. I believe for someone coming from an 8-bit platform like C64/Speccy/CPC it can be quite tricky adopting these concepts.

Originally Posted by tomcat666

- Scrolling using a big area and with all colours is VERY tricky to do on c64. You can use VSP but then your game won't work on all c64 versions. You can do nice and fast scrolling but limiting yourself to 4 colours. On Amiga it is VERY easy to scroll the bitmaps around and still have a lot of cpu left over to do all the tricks. And when you see what you can do with the copper and compare that to the Vertical Interrupts on the c64 where on some lines you are left with virtually zero cpu time you know what I am talking about.

I am far away of being a C64 guru but I believe I am informed well enough about the 6502, VIC and how to do certain things on this (racing-the-beam stuff, use of illegal opcodes).
But, again, these 'limitations' on the C64 lead to known solutions. If you want to create a sprite multiplexer on the breadbox, I assume you don't have very much options how to solve this. There are more options how to establish a bob/sprite engine on the amiga f.ex. feeding the blitter via cpu vs feeding the blitter via copperlist.

Originally Posted by tomcat666

- Blitter will help you immensly and basically make BOBs possible. Almost no c64 game uses the "bob" approach, you have to write a sprite multiplexer and mask the sprites, etc. to come anywhere near what you can much easily do on the amiga.

see above

Originally Posted by tomcat666

- Memory restrictions. While it is true that the graphics will take more memory on the amiga the actual memory you have for the game engine, precalc tables, AI, etc. is MUCH bigger on the amiga than on the c64.

I agree on this point.

Maybe this is one of the reasons why there are not so many new releases on the Amiga. You have more memory, more possibilities. Once I had the idea making an Amiga game which should not exceed 64KB or 256KB in size, so it could run on a plain A500. Once you limit yourself you're less likely to fall into the "lets make the next big thing" or "lets put this into the project,too" trap. And: the project stays lean.

Originally Posted by tomcat666

There are more things of course, but these are the main reasons why game *CODING* is easier on the Amiga than the C64.

However it seems to make quality graphics (and music) is proving next to impossible on the amiga these days. While we get games with graphics which are at least on par with the old days on the c64 (mostly even better) we get really crappy visual experience with new amiga games.

Where are the individuals who can create 2d art natively on the Amiga? It was said several times now that there are more graphicians/musicians out there than coders on the Amiga. Is this really true? I doubt that. Like I wrote in my previous post: things get complicated _nowadays_ when someone hast to draw graphics in a reduced environment. Back in the day people did not have 16,8 million colors. They did not have Ableton live and a plethora of synthesizers in their bedroom. One had a bunch of ST-xx disks and tried to make the best of it.
Please don't get me wrong: it is not about having "superb" graphics or music/sound, as that would imply that I am a superb coder (which I am not). Most of us are hobbyists. But just having usable graphics and sound for the given platform us not that easy as some of you might believe. You can find examples of these problem even here on this board.

Originally Posted by tomcat666

That is just not true. I did a lot of things on both platforms and actually coding a (quality) game is MUCH easier on an Amiga than on the c64:

- CPU ... 6502 1Mhz and 68000 7Mhz is a HUGE difference. It is much easier to code the engine, the AI, etc. on the Amiga than on the C64.

- Scrolling using a big area and with all colours is VERY tricky to do on c64. You can use VSP but then your game won't work on all c64 versions. You can do nice and fast scrolling but limiting yourself to 4 colours. On Amiga it is VERY easy to scroll the bitmaps around and still have a lot of cpu left over to do all the tricks. And when you see what you can do with the copper and compare that to the Vertical Interrupts on the c64 where on some lines you are left with virtually zero cpu time you know what I am talking about.

- Blitter will help you immensly and basically make BOBs possible. Almost no c64 game uses the "bob" approach, you have to write a sprite multiplexer and mask the sprites, etc. to come anywhere near what you can much easily do on the amiga.

- Memory restrictions. While it is true that the graphics will take more memory on the amiga the actual memory you have for the game engine, precalc tables, AI, etc. is MUCH bigger on the amiga than on the c64.

There are more things of course, but these are the main reasons why game *CODING* is easier on the Amiga than the C64.

However it seems to make quality graphics (and music) is proving next to impossible on the amiga these days. While we get games with graphics which are at least on par with the old days on the c64 (mostly even better) we get really crappy visual experience with new amiga games.

[appiah4]

If I could, I would probably program a text adventure in the vein of Infocom classics like Myth, Wonderland.

[TMR]

Originally Posted by Apollo

But, again, these 'limitations' on the C64 lead to known solutions. If you want to create a sprite multiplexer on the breadbox, I assume you don't have very much options how to solve this. There are more options how to establish a bob/sprite engine on the amiga f.ex. feeding the blitter via cpu vs feeding the blitter via copperlist.

It's more complicated than it might seem... there's a number of ways to multiplex on the C64, the simplest is to just have "zones" on screen that hardware sprites are restricted to; something like Delta does this with one area for the enemies and two more which are sometimes enabled for the scrolling backgrounds (they're hardware sprites as well, only the starfield and bullets aren't) with just the player's craft untethered so it can move around the entire playfield. There's a few variations on this as well where only some enemy sprites are recycled like the PD game Danger Zone which has one sprite reused half a dozen times for an asteroid field, but it still places tough restrictions on vertical movement for those sprites.

A sorting multiplexer (which is sometimes what people mean when they just say "multiplexer", the terminology isn't exactly set in stone) is a better option but that flexibility brings an extra level of complexity too and will munch it's way through resources like Pac-Man in a chemist's. The game has to A) run a sort of some kind and B) spend time each frame waiting around to reposition sprites, all of which are taking CPU grunt away from the other tasks that need to be running like game logic or the scrolling. The sort itself gives you a range of choices too and implementing some of the fastest sorts with two index registers and an accumulator can be "fun", but getting either the choice or implementation wrong can lead to serious problems later and the processing power isn't really there to "brute force" the job with a bubble sort.

(Well okay, in theory it can be done with bubble sorting but only by perhaps presorting things to reduce the odds of a worst case and trading the overheads off against everything else and.)

And now i'm going to run away and hide again. =-)

[tomcat666]

Originally Posted by TMR

B) spend time each frame waiting around to reposition sprites, all of which are taking CPU grunt away from the other tasks that need to be running like game logic or the scrolling.

Smart plexors don't do this... you can calculate how long before you need to position next sprite and setup the irq to that line (or about 2 lines above )... giving the main loop to perform game stuff in between.

[TMR]

Originally Posted by tomcat666

Smart plexors don't do this... you can calculate how long before you need to position next sprite and setup the irq to that line (or about 2 lines above )... giving the main loop to perform game stuff in between.

i was trying to illustrate things generally, but adding this kind of functionality is harder than not so it demonstrates the same point. Again, multiple solutions to one problem... =-)

[TMR]

Originally Posted by appiah4

If I could, I would probably program a text adventure in the vein of Infocom classics like Myth, Wonderland.

For the more experienced people out there, isn't there an Inform engine for the Amiga which could be used to do this...?

[Anubis]

Originally Posted by Pyromania

Some people really love the C64 and I can respect that. It was my first computer as well. But for me personally the Amiga was so beyond the C64 that it set the sun on my interest in that platform. I even thought in 1992 I needed a C64 again and bought an SX-64 cheap. But after two days I realized my C64 interest was over forever.

SX-64 was eye killer... with it's screen size.

[daxb]

I think the idea of a database or a fixed place known by everyone about game projects and maybe: "gfx/sfx... artis is offering for a game. Coder is searching for gfx/sfx/music for his game. ...". would be good. At least it could conect people in an easy way. This might be done by a person who isn`t a "game maker" or just has some internet skills and want to support in any way.

What about programmer who don`t want to make a game but want to support others doing it. Is there special code (what could be used several times/different projects) that is useful for game coders they could provide? A missing tool that could help? E.g. someone here asked for PicCon expansion.

Missing music:
If game music is needed what about to hold a competition like the scene party ones? Just write down some rules (eg. format: mod. filesize limit: 220kb. style: ambient. deadline is ... Winner will be the main theme. Second or rest in later levels for example. So people can win (for fame?) and can tell "I did the music for game x". This could attract people. Just the info must be spread as much as possible.

For graphics I havn`t an idea. Maybe someone else?

[Mrs Beanbag]

something like LinkedIn, where you can put up a sort of Hobby CV

[Lonewolf10]

Originally Posted by Mrs Beanbag

something like LinkedIn, where you can put up a sort of Hobby CV

If I need any graphics/music I usually just post a request in the "Request.Other" forum here on EAB

[saimon69]

@Lonewolf10

So seens at the end EAB has most of what we need, but very likely a better organization or a front-end where to retrieve it in an easier way could help

[NorthWay]

Originally Posted by TMR

the processing power isn't really there to "brute force" the job with a bubble sort.

Agree to disagree?

If you look at it, objects stay relatively relative to each other from frame to frame, and data that is mostly sorted is exactly what bubblesort loves.
If you are careful with your code and try to not add in more than one object every frame then one or two runs of cocktailsort should keep you sorted, and if you can also let your multiplexing splitter just drop sprites that are in the wrong order then you should have minimal blinking.

You are after all doing at least 50 passes over the sorting data each second ensuring you have mostly sorted data since your objects move smoothly across the screen.

[Mrs Beanbag]

Originally Posted by NorthWay

Agree to disagree?

If you look at it, objects stay relatively relative to each other from frame to frame, and data that is mostly sorted is exactly what bubblesort loves.

Insertion sort is better.

[Lazycow]

As there are at least some homebrew projects out there, what about creating a thread with links to all projects with one screenshot for each project? I would start it, but in which category? "Amiga scene"?

Everyone who knows a new homebrew project could post this or wirte me a mail and I amupdating the first post. I saw this in lemon64 forum for c64 and on nintendoage forum too. Sticky thread would be helpful at some point maybe.

[spud]

Lazycow, see the sticky at the top of this sub-forum:

http://eab.abime.net/showthread.php?t=68891