Should game devs have to support new hardware?

[DamienD]

Originally Posted by Steril707

On how many systems have you tested your "gracious" software?
Also, where can we download it?

grond has a habit of skipping questions he doesn't like i.e:

Originally Posted by DamienD

So, can we assume then that both of the above run on all of today's many different Amiga models / hardware setups; and your beloved Vampire?

Do you really expect anything less from a lawyer and the main Vampire spokesman? It's in his nature...

[grond]

Originally Posted by mcgeezer

I see, so you haven't written a game then on the Amiga.

Your point of view is to call other coders lazy and ignorant when it's pretty clear now that you don't have the credentials yourself to judge them with those kind of words. Therefore, I don't see anything to discard.

Blabla...

Lots of programmers can make stuff in assembler and have the sanctuary of the OS to shield them from making mistakes

If you word it like that, you suddenly come out much smarter. So why don't you go the easy route and use a more OS-friendly approach? I tell you why: because it is something you don't know how to do.

overall I'm now of the opinion that dev's target what they want

I agree to this part.

...and if it doesn't work on higher spec machines then tough (for the player and his/her hybrid Amiga).

I just think that, in this case, your code most probably is bad code.

[grond]

Originally Posted by Steril707

On how many systems have you tested your "gracious" software?
Also, where can we download it?

Are ad hominem attacks really all you have to offer? Some of my code is on pouet. A lot more of it is on my harddisk.

[Tigerskunk]

Originally Posted by grond

Are ad hominem attacks really all you have to offer?

No, but I have actually a finished Amiga production under my belt now on the contrary to you...
Took many years, but here I am.

Originally Posted by grond

Some of my code is on pouet. A lot more of it is on my harddisk.

I'd like to see something on the scale of what Graeme, PHX, Alpine9000 or I created so far.

Not too sound arrogant, but I am not sure you are exactly in the position to talk about the difficulties of Amiga game dev with "having written a few routines".

[mcgeezer]

Originally Posted by grond

Blabla...




If you word it like that, you suddenly come out much smarter. So why don't you go the easy route and use a more OS-friendly approach? I tell you why: because it is something you don't know how to do.




I agree to this part.



I just think that, in this case, your code most probably is bad code.

I'll tell you what bonny lad, come back and have a chat about game coding when you've made one. Until then, keep wishing and trying.

Let's heed the second post in this thread from Bippy and get things back on topic without the judgement from some.

[Tigerskunk]

Originally Posted by mcgeezer

Let's heed the second post in this thread from Bippy and get things back on topic without the judgement from some.

You are right.. Let's not escalate this... ; )

My point is simply, I need to decide for myself as someone producing content, what's fun for me (since earning money with this retro biz is a bullshit strategy), and I cannot be mad at somebody wanting something from me. But on the other side, that person cannot be mad at me for not wanting to do what he wants me to do.

It's actually that simple.

And if I want to create bad code that doesn't run on anything else than a stock A500 because I just feel it's so groovy to use fixed addresses like it's 1987, well, then that's my thing. If it made me happy while creating this, it's all fine.

And if someone thinks I am a shit coder because of this, well, then that's completely ok as well.

[mcgeezer]

I don't mind giving a classic error I made when I came back to the Amiga after 28 years.

This is from an early backup of Bomb Jack Beer Edition.

WAIT_FOR_FRAME:
	lea	CHIPBASE,a5	
.loop:	move.l	VPOSR(a5),d0
	and.l	#$1ff00,d0
	cmp.l	#303<<8,d0
	bne.b	.loop
	rts

Now that code works absolutely fine on an A500. When I ran the game on a faster Amiga the start round sequence in Bomb Jack ran 4 times as fast, all it did was move some hardware sprites.

I would reckon that bit of code (or something similar) was prevalent in an absolute shit tonne of games and demos from back in the day, it probably even came from my old source disks.

On faster Amiga's you then start to realise that because the CPU is so fast it is running the outer routines so quickly that it manages to run them multiple times on the same scan line, so when the scan line gets to line 303 it runs the routine mutliple times.

This is just one example of what I'm talking about, they are not crashes, in-experienced coders don't know any better and they've effectively followed the rules to the best of their knowledge.

There are plenty of other similar types of pitfalls.

[grond]

All you needed to know to avoid this type of mistake is in here:

http://amigadev.elowar.com/read/ADCD.../node000B.html
http://amigadev.elowar.com/read/ADCD.../node000C.html

I can't find my Amiga Hardware Reference Manual now but I'm sure it's been in there pretty much forever.

[DMWCashy]

Originally Posted by grond

Some of my code is on pouet. A lot more of it is on my harddisk.

Can you link us to this, EAB is about community and educating less experienced coders. Looking at your productions would be a great asset to the community and to the education of bad coders.

I also look forward to learning from your works.

[grond]

Originally Posted by Steril707

Not too sound arrogant, but I am not sure you are exactly in the position to talk about the difficulties of Amiga game dev with "having written a few routines".

Why would the validity of my point of view depend on what I have actually coded myself? If I tell nonsense because I lack the knowledge or experience, then it should be easy to debunk it using arguments. And, as it looks, I seem to be the only one here who actually did multi layer parallax scrolling on the Amiga entirely through the OS while keeping multitasking running (and, by the by, I wouldn't recommend doing it because of a significant shortcoming of AmigaOS I won't tell ).

[grond]

Originally Posted by DMWCashy

Can you link us to this, EAB is about community and educating less experienced coders. Looking at your productions would be a great asset to the community and to the education of bad coders.

I also look forward to learning from your works.

Yeah, sure, because that's what you are really interested in.

[mcgeezer]

Originally Posted by grond

All you needed to know to avoid this type of mistake is in here:

http://amigadev.elowar.com/read/ADCD.../node000B.html
http://amigadev.elowar.com/read/ADCD.../node000C.html

I can't find my Amiga Hardware Reference Manual now but I'm sure it's been in there pretty much forever.

I have mine next to me, let me know when you find yours so you can direct me to the page number.

Also, which paragraph in your links do you think applies to the code i posted?

[DMWCashy]

Originally Posted by grond

Yeah, sure, because that's what you are really interested in.

Becoming a better Amiga coder yes, please show us,

[BSzili]

Originally Posted by DMWCashy

Can you link us to this, EAB is about community and educating less experienced coders. Looking at your productions would be a great asset to the community and to the education of bad coders.

I also look forward to learning from your works.

He is way too seasoned to fall for this

[DMWCashy]

Grond needs to show his cards now, we are all calling.

[robinsonb5]

Originally Posted by mcgeezer

Also, which paragraph in your links do you think applies to the code i posted?

That would be the second link, third bullet point, second clause: "do not make assumptions about the order in which asynchronous tasks will finish." - which is valid advice, but also pretty vague, and could apply to pretty much all timing problems.
It's often hard to recognise an assumption as such. In your case you made an assumption that the hardware counter would change before your routine had completed - but until you found the problem you didn't *know* you'd made that assumption, which illustrates nicely how tricky this stuff can be.

[I've never programmed the Amiga's blitter directly, mind you; any insight I might have here comes from having dealt with concurrency issues in multi-threaded programming.]

[mcgeezer]

Originally Posted by robinsonb5

That would be the second link, third bullet point, second clause: "do not make assumptions about the order in which asynchronous tasks will finish." - which is valid advice, but also pretty vague, and could apply to pretty much all timing problems.
It's often hard to recognise an assumption as such. In your case you made an assumption that the hardware counter would change before your routine had completed - but until you found the problem you didn't *know* you'd made that assumption, which illustrates nicely how tricky this stuff can be.

[I've never programmed the Amiga's blitter directly, mind you; any insight I might have here comes from having dealt with concurrency issues in multi-threaded programming.]

Absolutely it is hard to spot, couple that with the assumption that "it worked then (back in the day) so it will work now" it adds to the problem.

This is all about gaining experience, but it would bloody well help everyone concerned if there was a way to just disable these accelerators through programming. Programmers would be happy, Users would be happy, Everyone happy.

[mcgeezer]

Originally Posted by grond

Why would the validity of my point of view depend on what I have actually coded myself? If I tell nonsense because I lack the knowledge or experience, then it should be easy to debunk it using arguments. And, as it looks, I seem to be the only one here who actually did multi layer parallax scrolling on the Amiga entirely through the OS while keeping multitasking running (and, by the by, I wouldn't recommend doing it because of a significant shortcoming of AmigaOS I won't tell ).

Let’s see it then.

[nikosidis]

The trend we see in Amigaworld now is that A500 is the star. That is the target for most.
060 is a lost case long time ago. The same for all NG Amigas including Vampire.
There are only 2 important Amiga configs. A500 1MB and standard A1200.
There is almost never done a game for any other config. At least not a original game of
any real quality. It will never happen either.

When I came back to Amiga I knew just what accelerator card I wanted for compatibility. A1200 with Blizzard IV.
It would be nice if I could just have one machine but it is not like that unless you only play games.
For games A1200 is perfect. For scene productions it is different. OCS machine is often needed.

Even if I like AGA I think OCS and 020 is my fav.. Amiga config. The beauty in the limitations of OCS and a little more grunt than 68000 when needed. That is kind of what we seen now with some recent game releases. It is ok to demand a little more than plain A500 as long as the game is playable on standard config. If not for possible expansions that would be difficult. I think it is great that we can get more out of our Amigas. First of all to have a snappy system to use whd-load. I would not recommend anything beyond 030.

Final conclusion.
If game is developed for A1200 it is no need to test on other hardware.
If game is developmed for A500 the game should be bested on A1200 standard config.
I even think it is no bad idea to put in some extras for A1200 config. Just like some did back in the day.

[Lineof7s]

I'd certainly rather have a bunch of Amiga coders writing "bad code" for A500/A1200 machines and learning as they go, than to lose them elsewhere having been put off by the elitism and gatekeeping in this thread and elsewhere because their Asteroids clone runs too quickly on a 68060 they'll never see in their lives.