Although so much time has passed, direct hardware programming continues to be considered a bad programming practice that would have been best avoided even when, in the Amiga days, it was so often a necessity dictated by project goals. This is clearly a purely ideological and short-sighted position, which deserves to be investigated and, then, stigmatised.

English: https://www.appuntidigitali.it/23936/directly-programming-the-amiga-hardware-was-not-a-bad-practice/

Nonostante sia passato così tanto tempo, la programmazione diretta dell'hardware continua a essere considerata una cattivissima pratica di programmazione che sarebbe stato meglio evitare anche quando, ai tempi dell'Amiga, era tante volte una necessità dettata dagli obiettivi di progetto. Si tratta chiaramente di una posizione puramente ideologica e miope, che merita di essere approfondita e, poi, stigmatizzata.

Italian: https://www.appuntidigitali.it/23810/programmare-direttamente-lhardware-dellamiga-non-era-una-cattiva-pratica/

@cdimauro

Back in the 80s, sure, but certainly not something that should have been the practice later.


There is one feature I really like about the Windows ecosystem: compatibility (especially video games). I'm an avid gamer and many of my favourite games are from the late 1990s, most of them work well directly or via wrappers and other "dark magic".

@cdimauro

So, the right way to do this be a game engine, the engine is abstraction between the game and hardware. This is the way of doing it works on A500. If you replace the game engine, you get game work with newer hardware, then as gradually the hardware becomes faster, you introduce the system friendly game engine.

Games can be divided into categories, moving objects, and the map. The parallax, sound and audio, the game engine is the OS, for the game. This way the game is hardware agnostic.

Some of the best games run in ScumVM.

Last edited by NutsAboutAmiga on 13-Oct-2024 at 09:26 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@pavlor

Quote:

pavlor wrote: @cdimauro Back in the 80s, sure, but certainly not something that should have been the practice later. There is one feature I really like about the Windows ecosystem: compatibility (especially video games). I'm an avid gamer and many of my favourite games are from the late 1990s, most of them work well directly or via wrappers and other "dark magic".

Let's say starting from mid 90s. After that the OS should have been the only way to program videogames.

So, basically when 3D was then primary type of video games.

3D = variable frame rate -> you don't need to do the best to reach 60/50 or 30/25 FPS.

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @cdimauro So, the right way to do this be a game engine, the engine is abstraction between the game and hardware. This is the way of doing it works on A500.

And A1200 as well.
Quote:

If you replace the game engine, you get game work with newer hardware, then as gradually the hardware becomes faster, you introduce the system friendly game engine.

Exactly. Once you've a lot more resources and you're not so constrained like with the A500 and A1200, you can think about using the OS.

Plus, the 3D direction which games were taking, as explained before.
Quote:

Games can be divided into categories, moving objects, and the map. The parallax, sound and audio, the game engine is the OS, for the game.

Well, parallax with the OS... you need the resources for doing it.

On Fightin' Spirit I've experimented adding the parallex to the bottom 64 lines of the screen, entirely using the Blitter for drawing the graphics but the CPU had to do a lot of calculations as well, and it was very demanding.
Quote:

This way the game is hardware agnostic.

You don't need the OS, in reality: you need good gaming libraries, which not all OSes provide.
Quote:

Some of the best games run in ScumVM.

Which are... adventures. That you likely could handle with the OS also on A500 and A1200.

@cdimauro

Quote:

entirely using the Blitter for drawing the graphics but the CPU had to do a lot of calculations as well, and it was very demanding.

Not demanding on a fast CPU.

Amos Kittens can run most of the AMOS games and programs, it uses chunky. Not planar,

Even this works:

https://www.youtube.com/watch?v=K5dOTx_JIwA

Last edited by NutsAboutAmiga on 13-Oct-2024 at 01:43 PM.
Last edited by NutsAboutAmiga on 13-Oct-2024 at 09:54 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @cdimauro Quote: entirely using the Blitter for drawing the graphics but the CPU had to do a lot of calculations as well, and it was very demanding. Not demanding on a fast CPU.

Which wasn't the option with the A500 or A1200.
Quote:

Amos Kittens can run most of AMOS games and programs, it uses chunky. Not planar, Even this works: https://www.youtube.com/watch?v=K5dOTx_JIwA

The frame rate isn't fluid, and the graphic is very poor.

I expect WAY MORE from an OS4 machine. That's even subpar of A500 games using parallax.

@cdimauro

The video is not on AmigaOS4, I expect UAE on windows or something...

Amos Kittens is fast, so I decided throw in lots artifact emulation on top of, for CRT scanlines etc.

LOL, not everyone like that.

In any case, your right games are made for a particular farme rate like 25 fps, or 30 fps, if the game runs at 60 fps, the game will run too fast.

It will be unplayable, Amos Kittens does suffer from this some places like “Castle AMOS�, its like when you play a snake game made for a 386 on Pentium 70Mhz.

Perhaps engines can be optimized more for speed, but the issue is the old games are too low resolution. It looks ugly no matter what. Of course, if I wanted to optimize graphics for speed their stuff that can be done to reduce the data transferee. Redrawing complete display is not efficient to display graphics.

Last edited by NutsAboutAmiga on 13-Oct-2024 at 01:42 PM.
Last edited by NutsAboutAmiga on 13-Oct-2024 at 12:05 PM.
Last edited by NutsAboutAmiga on 13-Oct-2024 at 12:04 PM.
Last edited by NutsAboutAmiga on 13-Oct-2024 at 12:03 PM.
Last edited by NutsAboutAmiga on 13-Oct-2024 at 11:58 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @cdimauro The video is not on AmigaOS4, I expect UAE on windows or something...

OK
Quote:

Amos Kittens is fast, so I decided throw in lots artifact emulation on top of, for CRT scanlines etc. LOL, not everyone like that.

Their problem: reproducing the scanlines is cool.
Quote:

In any case, your right games are made for a particular farme rate like 25 fps, or 30 fps, if the game runs at 60 fps, the game will run too fast. It will be unplayable, Amos Kittens does suffer from this some places like “Castle AMOS�, its like when you play a snake game made for a 386 on Pentium 70Mhz.

That's why PyGame has a wait to set the FPS to be generated for the game & graphic, and it will always runs at that speed (of course, you need a system which allows to do it).
Quote:

Perhaps engines can be optimized more for speed, but the issue is the old games are too low resolution. It looks ugly no matter what.

Assets can be changed...
Quote:

Of course, if I wanted to optimize graphics for speed their stuff that can be done to reduce the data transferee. Redrawing complete display is not efficient to display graphics.

Unfortunately, this is the modern way to generate graphics.

It looks inefficient compared to the Amiga way, but there's another thing that we have to consider: we have WAY more powerful hardware, which can do much better than the past.

@cdimauro

who claimed other? at that time hardware resources were limited so it was common to turn off the os and directly hit the hardware. On all home computers at that time

@OlafS25

Quote:

OlafS25 wrote: @cdimauro who claimed other?

Several comments on the posts that I've created on some Amiga Facebook's pages for the previous article.

There was a post from one of those guys just a few days ago that has shown how to use the audio.device for playing sound and which used it as an ("obvious"!) example for heavily complaining against who used/use direct hardware programming.

Even here, many times, some people (mostly Hypex and NutsAboutAmiga, which are the more active) finger pointed this "bad coding practice".
Quote:

at that time hardware resources were limited so it was common to turn off the os and directly hit the hardware. On all home computers at that time

But Amiga wasn't a home computer.

@cdimauro

https://www.appuntidigitali.it/23936/directly-programming-the-amiga-hardware-was-not-a-bad-practice/ Quote:

This stratagem makes it possible to achieve a hybrid approach, in fact, partially exploiting the s.o. for the start-up and subsequent launch of the actual code. But it involves some complications (e.g. the first disc would have to serve only that purpose, perhaps loading only the game’s introduction and leaving the other discs in their proprietary format) and does not represent the method popular at the time, i.e. floppies of games or demos that started immediately once inserted in the drive.

It looks like "s.o." should be "OS" judging by the context but OS is used everywhere else in the article in the correct letter ordering and without the acronym periods. My understanding is that English capital letter acronym periods are usually optional and more commonly omitted today than in the past. The acronym should be clear as to what it refers to and consistent use of periods looks better. What is the "s.o."? Perhaps this is some kind of language translation error?

OlafS25 Quote:

who claimed other? at that time hardware resources were limited so it was common to turn off the os and directly hit the hardware. On all home computers at that time

Most home/PC computers at the time barely had an OS. The CBM Pet, Apple II, CBM C64, Atari 400/800, etc. used ROM code from Basic as the OS with most of the memory used for user code. CP/M, MS-DOS, Mac OS, Sinclair QDOS and AmigaOS were more prototypical, dynamic and advanced OSs. Some of the expanding OS no longer fit in ROM and used valuable memory. The primary hardware resources you refer to are likely memory and CPU performance. The AmigaOS was removed too often when just considering the resources, especially with developer time considered where it was easier to retain the AmigaOS. The AmigaOS provided standard, easy to use and future proof hardware configuration and disk functions.

Memory constraints alone rarely justified removing the AmigaOS. The standard Amiga configurations had a low amount of memory and better code optimization and code density improvements could have improved the situation but the Amiga had options including large and fast standard floppy disk storage that exceeded the competition on the Amiga launch and for several years. This allowed dynamic loading and streaming of code and data. The Amiga dynamic libraries used this advantage as well as underutilized hunk overlays.

https://eab.abime.net/showpost.php?p=1665032&postcount=20 Quote:

The overlay feature fell out of favour when Amigas either shipped with more than 512 KBytes of memory, or could be expanded by adding memory plug-in cards (or something like the A590 for the Amiga 500). That was around 1988/1989, if memory (ha!) serves. The feature itself required preplanning, if you followed the original overlay management design (e.g. Lattice 'C' versions 3 & 4 and SAS/C versions 5 & 6). The documentation which covered how you made it work was decent enough, especially for SAS/C. You had to know in advance which portions of your program could be in memory at a time. Not every program could be conveniently broken down into such units, though. Manx Aztec 'C' did away with the minute preparations for keeping an exact subset of a program in memory, by virtue of its custom overlay manager. You could break down the program into units at the linker stage and then later load/unload portions of it as required. This was the method preferred by the industry by 1989/1990. But, as I mentioned, the constraints which required overlay support eventually went away as RAM became cheaper and Amigas became faster with each new iteration of the platform.

https://aminet.net/package/docs/misc/Overlay

There were a few Amiga programs which used hunk overlays including DPaint, EOB2 and Bane of the Cosmic Forge. Lack of documentation, early bugs and memory fragmentation may have been limiting factors. Virtual memory eventually became the standard for advanced OSs although a MMU is required and there are similar disadvantages. The memory limitation shifts to a performance limitation.

Performance limitations were the primary limiting factor for the Amiga. Early limitations were likely lack of documentation and Amiga experience by the developers as the Amiga was ahead of the competition but as Amiga was improving and the user base was expanding faster with the Amiga 500, the competition hardware was catching up and passed the Amiga which was standing still. Developers now understood the Amiga but had to resort to more and more extreme tricks to keep up. Granted, the Amiga had become cheaper than the competition as the next generation C64 that CBM wanted but more expensive competition hardware was exceeding the Amiga already in the late 1980s. CBM finally came out with a 68EC020+AGA@14MHz standard but it was too little too late.

Optimizing the AmigaOS would have improved both performance and reduced memory which would have allowed more games to keep the AmigaOS. However, the Amiga lack of performance competitiveness starting in the late 1980s due to failing to adequately and quickly upgrade the Amiga hardware would have still resulted in Amiga failure. More games using the AmigaOS would have made for an easier upgrade path. Fortunately, WHDLoad, patch programmers and the very easy to use and advanced 68k CPU and chipset saved the day for the 68k Amiga and allow it to move forward with compatibility. The large flat address space of the 68000 Amiga means WHDLoad games are less of a compatibility problem than 8/16 bit 808x/x86 games with Real mode, Unreal mode, System Management Mode, Protected mode, Virtual 8086 mode, Long mode and memory extensions like XMS, SXMS, EMS, EEMS, XMA, UMA, AWE, GEMMIS, etc. PC CGA/EGA/VGA/VESA support is likely not much different than OCS/ECS/AGA support. Amiga "NG" folks thought they could move forward while replacing the 68k Amiga and removing compatibility but compatibility is what allowed the 808x/x86 PC with much more baggage than the Amiga to become what it is today. Even though the 68k Amiga path forward has never been clearer, they persist perpetually actually impeding real attempts to revive the 68k Amiga.

There may have been other reasons to remove the AmigaOS. NDOS disks may have reduced piracy by making the disks more difficult to copy. Some programmers may have been following the trend because they saw more professional programmers remove the OS which some may have needed to do to push the hardware to the very limits. Programmers would turn off multitasking to save a couple of percent of CPU performance due to preemptive interrupts when there is no higher task/process ready to execute. It may have been possible to avoid this interrupt with better integrated hardware rather than using commodity CIA chips. RTOS embedded programmers want similar features that reduce system overhead to a minimum and allow to take over resources without removing the OS. The AmigaOS had some of those features. The AmigaOS is very thin/slim and modular, code sharing is excellent greatly reducing memory requirements, dynamic libraries are efficient, resources can be exclusively allocated and task switching overhead is RTOS like.

https://kgsvr.net/andrew/amiga/amiga.diffnt.html Quote:

AmigaOS is Efficient From: Shireman, Steve I have run control software on the Amiga booting off of a battery-backed SRAM PCMCIA card without a hard drive or floppy using only 4K of the PCMCIA card to boot. Think of the PCMCIA card as replacing the hard drive in a desktop system. The only RAM overhead was about 54K, and with this I have the full color model and mouse control, and fully preemptive multitasking and of the 2 Meg of RAM that comes with the A1200, The Amiga OS has only needed less than 1 / 10,000 of the RAM available. And I know it is using a few of the OO Objects in the Kickstart, but not very many. ... Fast Task Switching michael schulz wrote: A context switch on AmigaOS is much quicker than in some larger operating systems. Here are some context switch speeds for different machines/operating systems (in microseconds): o 26 uS for 25MHz Amiga A4000/040 AmigaOS 3.1 o 71 uS for 100MHz Pentium Linux 1.2.13 o 89 uS for 233MHz AlphaStation 255/233 Digital Unix 3.2 o 102 uS for 150MHz DEC 3000/300 OSF/1 2.0 o 106 uS for 66MHz Snake HP-UX 9.x o 126 uS for 25MHz Amiga A2000/030 AmigaOS 2.1 o 128 uS for 40MHz Viking SunOS 4.1.3 o 131 uS for 167MHz SPARC Ultra-1 Solaris 2.5 o 210 uS for 33MHz 486 386BSD 0.1 o 212 uS for 50MHz RIOS AIX 3.2

Other AmigaOS advantages are mentioned in the document linked above with many being RTOS features. The AmigaOS is good in this regard but it could have been better with better compilers and assembler optimizations where worthwhile and better hardware support (the AmigaOS may have been avoided in some cases due to limited/immature APIs). Programmers deserve some of the blame for jettisoning the AmigaOS too quickly. CBM deserves some of the blame for not upgrading to better hardware standards faster. More modern PPC AmigaOS and emulation of the 68k and chipset moved vastly away from these advantages trying to turn the AmigaOS into a desktop behemoth. The 68k hardware and chipset are an important part of the elegance of the Amiga no matter the level of abstraction used.

Last edited by matthey on 15-Oct-2024 at 12:15 PM.
Last edited by matthey on 14-Oct-2024 at 11:53 PM.
Last edited by matthey on 14-Oct-2024 at 10:57 PM.
Last edited by matthey on 14-Oct-2024 at 08:16 PM.

@matthey

Quote:

matthey wrote: @cdimauro https://www.appuntidigitali.it/23936/directly-programming-the-amiga-hardware-was-not-a-bad-practice/ Quote: This stratagem makes it possible to achieve a hybrid approach, in fact, partially exploiting the s.o. for the start-up and subsequent launch of the actual code. But it involves some complications (e.g. the first disc would have to serve only that purpose, perhaps loading only the game’s introduction and leaving the other discs in their proprietary format) and does not represent the method popular at the time, i.e. floppies of games or demos that started immediately once inserted in the drive. It looks like "s.o." should be "OS" judging by the context but OS is used everywhere else in the article in the correct letter ordering and without the acronym periods. My understanding is that English capital letter acronym periods are usually optional and more commonly omitted today than in the past. The acronym should be clear as to what it refers to and consistent use of periods looks better. What is the "s.o."? Perhaps this is some kind of language translation error?

Yes, it escaped from the translation. Now fixed, thanks.

s.o. is exactly OS, but in Italian. In our language first comes the noun, and then follows the qualifier/adjective: the exact opposite of English and other languages (German too).
Quote:

OlafS25 Quote: who claimed other? at that time hardware resources were limited so it was common to turn off the os and directly hit the hardware. On all home computers at that time Most home/PC computers at the time barely had an OS. The CBM Pet, Apple II, CBM C64, Atari 400/800, etc. used ROM code from Basic as the OS with most of the memory used for user code. CP/M, MS-DOS, Mac OS, Sinclair QDOS and AmigaOS were more prototypical, dynamic and advanced OSs. Some of the expanding OS no longer fit in ROM and used valuable memory. The primary hardware resources you refer to are likely memory and CPU performance. The AmigaOS was removed too often when just considering the resources, especially with developer time considered where it was easier to retain the AmigaOS. The AmigaOS provided standard, easy to use and future proof hardware configuration and disk functions. Memory constraints alone rarely justified removing the AmigaOS. The standard Amiga configurations had a low amount of memory and better code optimization and code density improvements could have improved the situation but the Amiga had options including large and fast standard floppy disk storage that exceeded the competition on the Amiga launch and for several years. This allowed dynamic loading and streaming of code and data. The Amiga dynamic libraries used this advantage as well as underutilized hunk overlays. https://eab.abime.net/showpost.php?p=1665032&postcount=20 Quote: The overlay feature fell out of favour when Amigas either shipped with more than 512 KBytes of memory, or could be expanded by adding memory plug-in cards (or something like the A590 for the Amiga 500). That was around 1988/1989, if memory (ha!) serves. The feature itself required preplanning, if you followed the original overlay management design (e.g. Lattice 'C' versions 3 & 4 and SAS/C versions 5 & 6). The documentation which covered how you made it work was decent enough, especially for SAS/C. You had to know in advance which portions of your program could be in memory at a time. Not every program could be conveniently broken down into such units, though. Manx Aztec 'C' did away with the minute preparations for keeping an exact subset of a program in memory, by virtue of its custom overlay manager. You could break down the program into units at the linker stage and then later load/unload portions of it as required. This was the method preferred by the industry by 1989/1990. But, as I mentioned, the constraints which required overlay support eventually went away as RAM became cheaper and Amigas became faster with each new iteration of the platform. https://aminet.net/package/docs/misc/Overlay There were a few Amiga programs which used hunk overlays including DPaint, EOB2 and Bane of the Cosmic Forge. Lack of documentation, early bugs and memory fragmentation may have been limiting factors. Virtual memory eventually became the standard for advanced OSs although a MMU is required and there are similar disadvantages. The memory limitation shifts to a performance limitation.

Ovelays could be used in programs, but unlikely on games, where you've a single, small, code base which remains "unique" (the business logic, mostly) and that cannot swapped (it's entirely "live"). Different code might be loaded when you've a different level / map, for example, but usually you've another copy on the new floppy and the problem is easily solved.

Games are dominated by assets, and here depends on the type of game: some might require all assets in memory (Fightin' Spirit, for example), and others can have some of them streamed from the disk when needed (USA Racing, for example. But here I've opted to have everything in memory, because I've found a way keep all 640 32x32x32 colours tiles).
Quote:

Performance limitations were the primary limiting factor for the Amiga.

Not all the time (see below). But performance issues were unavoidable.
Quote:

There may have been other reasons to remove the AmigaOS. NDOS disks may have reduced piracy by making the disks more difficult to copy.

This could be done using the OS as well. But it's easier without the OS.
Quote:

Some programmers may have been following the trend because they saw more professional programmers remove the OS which some may have needed to do to push the hardware to the very limits.

Monkeys... They should have done what's really needed and not just following the trend.
Quote:

Programmers would turn off multitasking to save a couple of percent of CPU performance due to preemptive interrupts when there is no higher task/process ready to execute.

Disabling multitasking and interrupts for long periods is forbidden from Commodore's guidelines.

If you've to use the OS, you've to follow all rules. Otherwise it's better to switch to bare metal.
Quote:

It may have been possible to avoid this interrupt with better integrated hardware rather than using commodity CIA chips.

But we had... what we had: CIAs for timers & generating proper interrupts.
Quote:

RTOS embedded programmers want similar features that reduce system overhead to a minimum and allow to take over resources without removing the OS. The AmigaOS had some of those features. The AmigaOS is very thin/slim and modular, code sharing is excellent greatly reducing memory requirements, dynamic libraries are efficient, resources can be exclusively allocated and task switching overhead is RTOS like. https://kgsvr.net/andrew/amiga/amiga.diffnt.html [quote] AmigaOS is Efficient From: Shireman, Steve I have run control software on the Amiga booting off of a battery-backed SRAM PCMCIA card without a hard drive or floppy using only 4K of the PCMCIA card to boot. Think of the PCMCIA card as replacing the hard drive in a desktop system. The only RAM overhead was about 54K, and with this I have the full color model and mouse control, and fully preemptive multitasking and of the 2 Meg of RAM that comes with the A1200, The Amiga OS has only needed less than 1 / 10,000 of the RAM available. And I know it is using a few of the OO Objects in the Kickstart, but not very many.

54kB of memory used by the OS isn't that much, but the main problem is that it might be scattered over the entire memory map.

You don't know how big could the biggest available chunky of memory and how much of the remaining blocks are available and could be used.

More important, there could be memory alignment restrictions due some reasons, and you might end up trashing a lot of memory allocating memory with the OS to get the proper alignment. An example: having 64kB of memory aligned to... 64kB. You can do it for sure, and then you can try to reused the unaligned memory instead of cutting it of, but it's a nightmare.

Last but not really least, allocating memory required to use pointers for all data structures. Whereas with a (almost) fixed memory map you don't needed them (at least for most of the data structures).

In short: having a certain amount of free/available memory from the system is just the tip of the iceberg, because games have other, different requirements, which might easily not be satisfied.
Quote:

... Fast Task Switching michael schulz wrote: A context switch on AmigaOS is much quicker than in some larger operating systems. Here are some context switch speeds for different machines/operating systems (in microseconds): o 26 uS for 25MHz Amiga A4000/040 AmigaOS 3.1 o 71 uS for 100MHz Pentium Linux 1.2.13 o 89 uS for 233MHz AlphaStation 255/233 Digital Unix 3.2 o 102 uS for 150MHz DEC 3000/300 OSF/1 2.0 o 106 uS for 66MHz Snake HP-UX 9.x o 126 uS for 25MHz Amiga A2000/030 AmigaOS 2.1 o 128 uS for 40MHz Viking SunOS 4.1.3 o 131 uS for 167MHz SPARC Ultra-1 Solaris 2.5 o 210 uS for 33MHz 486 386BSD 0.1 o 212 uS for 50MHz RIOS AIX 3.2

Well, context switch is absolutely irrelevant and not need for games.
Quote:

Other AmigaOS advantages are mentioned in the document linked above with many being RTOS features. The AmigaOS is good in this regard but it could have been better with better compilers and assembler optimizations where worthwhile and better hardware support (the AmigaOS may have been avoided in some cases due to limited/immature APIs). Programmers deserve some of the blame for jettisoning the AmigaOS too quickly. CBM deserves some of the blame for not upgrading to better hardware standards faster. More modern PPC AmigaOS and emulation of the 68k and chipset moved vastly away from these advantages trying to turn the AmigaOS into a desktop behemoth. The 68k hardware and chipset are an important part of the elegance of the Amiga no matter the level of abstraction used.

The problem is... we had what we had at the time, and there's little that could be changed.

Besides (strictly) following the guidelines: this could and SHOULD have been made.

@cdimauro

AmigaOS do it obviously, but I get your point.

@kamelito

Quote:

kamelito wrote: @cdimauro AmigaOS do it obviously, but I get your point.

Unfortunately, the OS can't do many things.

If you want to get a bit closer to the bare metal you've to acquire & use the needed resources and then manually & directly program them.

But, yet, you can't do OTHER things. Some I've reported here, some others here:
https://www.facebook.com/groups/CommodoreAmiga/posts/10160659006129157/?comment_id=10160659078824157&reply_comment_id=10160661681259157

and some examples here:
https://www.facebook.com/groups/CommodoreAmiga/posts/10160659006129157/?comment_id=10160660090309157&reply_comment_id=10160663919624157

@cdimauro

In the article you say
Quote:

I’d be really curious to know, otherwise, how Fighin’ Spirit and USA Racing (the games I worked on. The latter not released) could have been made using only the OS

How serious are you about this? Serious enough to release the source code?

Can you explain in detail what things you did in Fighin’ Spirit that 'there's no way that you can realize them using the OS, even in the hybrid mode'?

I think one of the reason most programmer didn't bang the metal is because they wanted games and ports to be easy. There not that many Amiga Exclusive titles. Plus also I think we forget the easy access to resources and finding out how things work now, thanks to the internet. Back then, it would of been what ever book about the Amiga architecture that you had to relied on.

Also optimization, getting frames rate up and improving graphics etc, ok some programmers would do the work, but my guess is once its working, very few would have the time, budget and resources to go and improve it.

Last edited by amigang on 22-Oct-2024 at 10:57 AM.

_________________
AmigaNG, YouTube, LeaveReality Studio

@cdimauro

Quote:

There was a post from one of those guys just a few days ago that has shown how to use the audio.device for playing sound and which used it as an ("obvious"!) example for heavily complaining against who used/use direct hardware programming.

It would likely be less overhead directly programming Paula. The audio device needed an IORequest for each channel. But it didn't IMHO provide enough hardware abstraction, as things like frequency were not directly supported and had to be specified as a low level period value which differed depending on clock. I tend to think it would have been easier to offer an audio library that wasn't constrained by singular threading device model forcing duplicates of device objects to compensate.

Quote:

Even here, many times, some people (mostly Hypex and NutsAboutAmiga, which are the more active) finger pointed this "bad coding practice".

Like what? The audio device? LOL.

Have you got an example? For all the times I can't think of one finger pointing "bad coding practice" example.

Quote:

But Amiga wasn't a home computer.

I thought it was a HC. It came out after the post micro era. Though some micros, such as the C64, listed personal computer on the box.

Earlier...

Quote:

It looks inefficient compared to the Amiga way, but there's another thing that we have to consider: we have WAY more powerful hardware, which can do much better than the past.

Depends how you look at it. The example you gave for blitter scrolling might not look like the best way compared to the live scrolling way without needing to modify bitmap. But, scrolling was one feature of the blitter, which games used when sprites or hardware scrolling were not possible for the desired effect. In fact I've read a few games used the blitter for all sorts of applications including sprites (or BOBs as they were). So, the player sprite was not always a hardware sprite with enemies blitted on, which is how I think of it being done efficiently.

Today's hardware may lack sprites, however redrawing the screen was what the blitter was doing, so using hardware to composite screen object layers can be comparable to using blitter for drawing to bitmap.

Last edited by Hypex on 22-Oct-2024 at 02:02 PM.

@bhabbott

Quote:

bhabbott wrote: @cdimauro In the article you say Quote: I’d be really curious to know, otherwise, how Fighin’ Spirit and USA Racing (the games I worked on. The latter not released) could have been made using only the OS How serious are you about this?

I'm always serious. Unless when I'm not serious...
Quote:

Serious enough to release the source code?

That's not needed, elementary logic at the hand.

In fact, the most simple proof of that is that Fightin' Spirit (and USA Racing as well) was using almost all available memory (512kB Chip RAM + 512kB Fast/Slow RAM).
Besides that, assets (and the bitplanes of the screens) were carefully allocated in memory, with precise alignments to minimize the waste of memory.
If you combine both things, there's no way that the OS could be used for the same, since it requires much more memory.
Quote:

Can you explain in detail what things you did in Fighin’ Spirit that 'there's no way that you can realize them using the OS, even in the hybrid mode'?

See above. But I give a second, much more technical, proof (and I stop here, because it's enough, since it's another one) is that it had two screens, one at the top (without scrolling) for some information, and then the bigger one which was showing the concrete content and it was capable of multidirectional scrolling.
As you you should know, using OS' screens to simulate the same require some raster lines to separate them, which are needed to setup the second screen.
In Fightin' Spirits (and same for USA Racing, of course) all registers with fixed content were already preloaded by the CPU with proper values, and the two copperlists (because FS is running at 25FPS. USA Racing had only one copperlist, because it was running at 50FPS) only had the very bare minimum of Copper instructions required to change the bitplane pointers and set the scroll values, for example.
However, FS was using double buffering + the screen keeping the (untouched) background. So, in total there were three screens (four, considering the top one), each one was 576x256 (in 64 colours). The interesting thing is that the two screens used for the double buffering hadn't such full size, because I've implemented a technique (directly borrowed from USA Racing) that allowed to used a bit more than half the size. So, saving A LOT of memory. That's something which cannot be implemented using the OS APIs (unless you completely kick out the OS when displaying the system View, and you build your own custom copperlists).
USA Racing is even more complicated, because it had a single screen (in 32 colours) with multidirectional scrolling of up to 800 pixels/s in each direction. You have no idea on how I've implemented it to efficiently use the memory and all graphic operations. Anyway, it's something impossible using the OS (unless, again, you kick out the OS and you create your own View / copperlist).

Is it enough?

Quote:

It looks inefficient compared to the Amiga way, but there's another thing that we have to consider: we have WAY more powerful hardware, which can do much better than the past.

That’s true, but we have higher resolutions with lot’s more pixels. 1024, 4K, and even 8K,
720p is pretty much the standard people use on workbench these days.

Even if AmigaONE’s are powerful, they are not as powerful as a normal PC, so clipping region, and smart refresh techniques does lower CPU, and it does lower bandwidth.

I tried in EUAE to remove region detection code, to see if it was possible reduce overhead on EUAE read and write, to EUAE Picasso96, but end result was less optimal, when I did that, cost of copy complete screen at 60 FPS, compared to finding region, as way bigger.

If nothing is updated in EUAE p96, then nothing need to copied to graphic card, and result smart refresh almost always wins.

perhaps if all pixel are updated every frame, then smart refresh is bad, but I did get that far, I got pissed off by someone.

There is big difference between DDR2 and DDR3 memory no doubt.
Perhaps what is true for X1000 is not true for X5000, something to keep in mind when optimizing.

Last edited by NutsAboutAmiga on 22-Oct-2024 at 07:26 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS