Is the Amiga hard to program?

[jotd]

Besides learning the basics (which is A LOT) what I find difficult is making something work, then realizing that it's too darn slow because of overestimated blitter performance, poor CPU performance (for 3D games), lack of planning when designing your tasks

IMHO, if you don't use parallelism (blitter + cpu when the blitter is working) your 2D game will crawl. If you don't use the blitter, the game will be slow too (some games don't use the blitter at all, like Wicked, and a lot of ST ports. Not great)

Also using a high level language can introduce a lot of overhead because of old compilers that generate poor 68k code. Select your compiler carefully, or use assembly.... Best one around seems to be Bartman's VS Code gcc 10 plugin.

For sound, you can do a lot of things with off-the-shelf components. Like phx ptreplay. And forget about it. It's great.

Some engines developped recently look very good. Ex: Scorpion engine. I don't know about the overhead, but it looks good. Of course, people who know asm / C / C++ have another language to learn... Or AMOS....

[fxgogo]

So the Raspberry Pi foundation have a good book on learning C++. Would that learning be applicable to Amiga C++? I mean I would not expect a full 1-1 compatibility, but for the basics, would it help?

[Bruce Abbott]

Originally Posted by saimon69

[polemic]
Wow, sound REALLY like Amiga is a religion: "Read the Bible*"


*bible as RKRM, but we are there
[/polemic]

Yes. the RKMs are the AMiga's 'bible'. But just like - even if you aren't a Christian - you can't fully understand Christianity without reading the Bible, so you can't really understand the Amiga until you have read its technical manuals.

Perhaps you can find out all you need to know from secondary sources, but it will be a mishmash of fragmented knowledge that is bound to be incomplete, and perhaps give you a wrong impression about some stuff. The RKMs give you an overview of the Amiga from the people who designed it, so you get to how they intended it to be used. This will make it easier for you to understand how it actually works.

RKRM has the LITTLE problem that assumes people know C at a middle/advanced level to understand what is going on

I program exclusively in assembler (except when tweaking existing code), but I don't recommend it for system programming even though I do it myself. The OS has minimal checks for bad parameters and will quickly become unstable or crash from silly mistakes that wouldn't happen in C. Most of the OS is written in C and most example code is too, but this is not a big problem for the assembly language programmer once you realize that in many ways C is only a small step above assembly language anyway.

The main reason you might want to program the Amiga in assembler is to do stuff that hits the hardware. So you will be happy to know that the Hardware Reference Manual has numerous asm examples. Some RKM example code is also written in assembler, including a 'ramdev' device, an ILBM packing routine, program startup code, and a run-time library.

[jotd]

at least when using C when calling the API you can't make mistakes with register parameters. Such mistakes are lethal in asm (lockup/freeze/guru)

[gimbal]

I have no fond memories of that when doing development for DOS. Put one wrong value in a register and boom... reboot needed. Good luck debugging a problem when the result is a hanging OS :/

[roondar]

Originally Posted by fxgogo

So the Raspberry Pi foundation have a good book on learning C++. Would that learning be applicable to Amiga C++? I mean I would not expect a full 1-1 compatibility, but for the basics, would it help?

It should help you learn the language, certainly. The only real issues I see are that using the C++ STL might not always be a good fit for the Amiga OS (mind you, it should work but the performance of it will be very much implementation dependent) and that the Amiga OS/HW is rather unique so many of the features the Amiga offers can really only be learned on an Amiga itself.

There used to be an argument that C was a better pick than C++ for performance reasons, but I'm not certain that still applies today with the newer gcc versions being out now.

[Tigerskunk]

Originally Posted by saimon69

Well, now am adding the million dollar question:

if someone completely new to Amiga programming (like in example me) want to start, without telling him 'go check this and that' on books and such, what would be the ground level hints that he would need to understand how to begin to do something? How he would need to lay down base bricks?

(as base steps, then the language will come later)

What do you want to code? A game or a Workbench/OS program?

[TroyWilkins]

Originally Posted by trydowave

is the amiga hard to program for or something? been watching clips of the crap fest strider II by tiertex. the amiga version is choppy with tiny sprites and the game gear version is the complete opposite. being its the same company how comes it so hard for them to make an amiga game with decent scrolling?

This is the case for a lot of amiga games, especially arcade ports. After u see the likes of Turrican you wonder why the amiga never had a great version of say strider?

A direct comparison of an Amiga game and a Game Gear game presents a number of problems.

The Game Gear has a much lower resolution screen. Game gear games have a resolution of 160 × 144 pixels, while most Amiga games have 320 x 200 or even more pixels.

Sprites: The Game gear has 64 8x8 sprites, while the Amiga has "only" 8 sprites. Sure, the Amiga can have the sprites multiplexed so they can be "reused" (as long as they don't occupy the same scanline), and they're larger, 16 pixels wide and up to the height of the screen. But if the programmer doesn't want to deal with multiplexing the sprites, that difference of 64 sprites vs 8 is a big one.

There is also the issue of experience with the different platforms. Someone who is very experienced with the Amiga can really make it sing and dance, but if they've never programmed the Game Gear (for example), their first game may not be as good as it could be. And it goes the opposite way - a Game Gear programmer who has never made an Amiga game will probably not understand the ways of getting the best out of the Amiga.

[sokolovic]

I didn't have the times to play with it but doesn't the work done with the Scorpion Engine, especially the latest versions, by Earok moderate a bit the assertation that the Amiga is hard to code or would be bad at parallaxes ? Examples of what can be done now with this engine are stunning

[Tigerskunk]

Originally Posted by sokolovic

I didn't have the times to play with it but doesn't the work done with the Scorpion Engine, especially the latest versions, by Earok moderate a bit the assertation that the Amiga is hard to code or would be bad at parallaxes ? Examples of what can be done now with this engine are stunning

a) Using Scorpion Engine is not coding.
b) what you are talking about is not real parallax but scrolling repeating patterns in different speeds per scanline.

Sorry for being pedantic here...

[sokolovic]

Originally Posted by Steril707

a) Using Scorpion Engine is not coding.
b) what you are talking about is not real parallax but scrolling repeating patterns in different speeds per scanline.

a) yeah but my point was IF you can manage such a quality with the Scorpion Engine, you could imagine what can be achieved by coding directly the hardware.


b) This is a coder point of view. For a non specialist, it ends up to be a perfect parallax, AKA an effect "where background images move past the camera more slowly than foreground images, creating an illusion of depth in a 2D scene of distance" (I'm quoting WP)

Originally Posted by Steril707

Sorry for being pedantic here...

You're absolutely not. And thanks again for Inviyya (another example proving that Amiga isn't bad at parallaxes btw)

[mcgeezer]

The Amiga is a great machine, but to get the best out of it you have to learn how to use it - just like anything else.

Its weakness as a games platform is that it doesn't have a tile-mapped display where the likes of the old 8 bit and 16 bit games consoles do. I'd therefore argue that making games on those old platforms are far easier than on the Amiga.... then there's the mass of extra hardware ... but we don't wanna go there again.

Is it hard to program for ... compared to a C64? Yes
Is it hard to program for ... compared to an Atari ST? No
Is it hard to program for ... compared to using an engine? ... it's not a valid comparison.

[gimbal]

Originally Posted by sokolovic

you could imagine what can be achieved by coding directly the hardware.

Well yes but I don't need Scorpion Engine for that as there actually are a good number of games which leave nothing to the imagination when it comes to using the hardware appropriately. It has been discussed quite thoroughly on this very forum.

[NorthWay]

Read the HRM and get the startup/shutdown snippets you can find online - I suggest studying that to understand why you need to go through those procedures before your code runs. Then you can skip the RKRM if you don't want to have the OS do your lifting.
(For fully throwing out the OS you probably need a good deal of experience in Amiga coding.)

[phx]

Originally Posted by saimon69

You know why i ask this? Because while for programming 8-bit machines all you seem to need is a memory location diagram, Amiga programming is not made that way;

Depends what you want to do. If you don't want to use the OS at all, you can choose to do so (for example for a game or demo) and all you need is your memory location diagram (AKA the register descriptions in the Hardware Reference Manual).
The only difference is that you have to disable the OS in a clean way first. As others already indicated there are a lot of such startup routines available and you don't even have to understand them in detail.

Originally Posted by saimon69

RKRM has the LITTLE problem that assumes people know C at a middle/advanced level to understand what is going on

Bruce also mentioned the HRM. There is no C in it. Just some example code in assembler.

If you want to do OS programming (for a Workbench application) then you need the RKM instead. Those are really two different worlds. The worst thing to do is mixing hardware hacking with OS compliant code.

Originally Posted by roondar

There used to be an argument that C was a better pick than C++ for performance reasons, but I'm not certain that still applies today with the newer gcc versions being out now.

All these object oriented concepts don't come for free. They look elegant in a C++ source, but not in machine code. Plain C code allows for a more direct translation into assembler programs.

Originally Posted by mcgeezer

Is it hard to program for ... compared to an Atari ST? No

Considering that the AmigaOS is much more complex than TOS and the Amiga custom chip hardware is much more complex than the stock chips on the ST ... I tend to disagree.

[roondar]

Originally Posted by phx

If you want to do OS programming (for a Workbench application) then you need the RKM instead. Those are really two different worlds. The worst thing to do is mixing hardware hacking with OS compliant code.

100% this. This is advice you've given before and it's very, very good advice. Don't mix the OS and the hardware, been there, saw it blow up, done with it.
That said, I would say that having a starting point with the OS up and then killing it for the duration of the program on startup also feels acceptable to me.

All these object oriented concepts don't come for free. They look elegant in a C++ source, but not in machine code. Plain C code allows for a more direct translation into assembler programs.

That does make sense, I was mostly wondering because the C/C++ situation on the Amiga changed recently with the brilliant new gcc versions coming out.

Considering that the AmigaOS is much more complex than TOS and the Amiga custom chip hardware is much more complex than the stock chips on the ST ... I tend to disagree.

I guess it depends. In some ways, the ST (though not STE) would be easier as the lack of hardware means you don't have to worry about not using it correctly. On the other hand, it does mean you'd have to figure out all the algorithms for the GFX/Audio stuff yourself and that may or may not be that easy.

[mcgeezer]

Originally Posted by phx

Considering that the AmigaOS is much more complex than TOS and the Amiga custom chip hardware is much more complex than the stock chips on the ST ... I tend to disagree.

exploring this a little bit more then...

Let's say you want to do a full screen horizontal scrolling game on the Amiga and on the ST at 50hz.... (a pretty standard thing for games to do).

Which platform do you think that can be achieved on the easiest?

[Tigerskunk]

The ST's bitplane layout is a nightmare though. Since I invested some time learning about it my respect for anybody who got something done on the ST rose a good bit.
On the other side, this kind of intrigues me since I love getting the most out of hardware.

[mcgeezer]

Originally Posted by Steril707

The ST's bitplane layout is a nightmare though. Since I invested some time learning about it my respect for anybody who got something done on the ST rose a good bit.
On the other side, this kind of intrigues me since I love getting the most out of hardware.

I've always said this is why I respect the ST programmers a huge amount.

The stuff they did with the hardware was exceptional. Look no further than Enchanted Land on the ST which was a technical masterpiece of the machine yet on the Amiga it's nothing special.

[Tigerskunk]

Originally Posted by mcgeezer

I've always said this is why I respect the ST programmers a huge amount.

The stuff they did with the hardware was exceptional. Look no further than Enchanted Land on the ST which was a technical masterpiece of the machine yet on the Amiga it's nothing special.

Yep.
And that's whats intruiging me. Must be fun to get something crazy out of it that hasn't been done before. The Amiga is a much more capable machine, but its capabilities are also more confining how you want to use it