Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
|
|
|
|
Poster | Thread | NutsAboutAmiga
|  |
Re: Directly programming the Amiga hardware was not a bad practice! Posted on 24-Oct-2024 16:56:32
| | [ #41 ] |
| |
 |
Elite Member  |
Joined: 9-Jun-2004 Posts: 12960
From: Norway | | |
|
| @OlafS25
I know of some stuff, as a user, not as developer.
I read some of the readme’s very quickly, and what I can see, most of the libraries are from 1998 around that time, there are some earlier libraries. Most of the libraries are not focused on cross-platform targeting, some of the libraries are for converting graphics, and I don't believe they set up the display provide the a basic framework to allow cross-platform type of game.
a good framework should, hide the low level complexity, it should provide a simple way to managed objects which are used within a game engine, it's not interesting from the game's point of view if the graphics is chunky or if it's planar, just that it has to be render owns a certain coordinate, the actual drawing of the individual parts or how to refresh or how to cut and merge, graphics, these are the giddy details that takes up time, To develop, and adds no value to the game.
Some of the libraries are focusing on standardizing the graphics, but it seems like they lost interest while developing the library, Are incomplete library that does not standardize the graphics systems are of any value, and sadly it doesn't look like there were much interest from other developers, that happens a lot in development because of ego, and then you have a great idea somebody want to make a copy of your ide rather than cooprate on your project, I've seen this with the UTF library I wrote some time ago that, but it was used as an example rather than actually being used as is any project, as it was intended to be used, this means that the the library wasn't optimized or didn't get any benefit of being open sourced, the end result is that the software that is based on the code but not on the library, probably will never have any benefit of any optimization of the library, and that sucks. _________________ http://lifeofliveforit.blogspot.no/ Facebook::LiveForIt Software for AmigaOS |
| Status: Offline |
| | OlafS25
|  |
Re: Directly programming the Amiga hardware was not a bad practice! Posted on 24-Oct-2024 17:05:27
| | [ #42 ] |
| |
 |
Elite Member  |
Joined: 12-May-2010 Posts: 6472
From: Unknown | | |
|
| @NutsAboutAmiga
from what I read on aminet it seems 1998 was the year of highest number of uploads and activity on aminet and then it rapidly went down. I included a lot of shared libraries in my distribution for all sort of challenges, there were f.e. a lot of different libraries to create better looking GUIs, but propably most not often used and thus bugfree and developments stopped. In some cases with sources, in others not. A huge code-base, much bigger than on any NG platform. |
| Status: Offline |
| | cdimauro
|  |
Re: Directly programming the Amiga hardware was not a bad practice! Posted on 24-Oct-2024 19:42:14
| | [ #43 ] |
| |
 |
Elite Member  |
Joined: 29-Oct-2012 Posts: 4127
From: Germany | | |
|
| @bhabbott
Quote:
bhabbott wrote: @cdimauro
Quote:
cdimauro wrote:
Since you've retired and have a lot of free time, |
I am NOT retired, but I will be soon. Unfortunately that doesn't mean I will have a lot of free time, as I have a lot of existing projects to finish before starting on anything new.
Quote:
you can try yourself writing a small demo showing a multiway scrolling screen up to 800 pixel/s in each direction. 32 colours. A top 320x16 screen of 16 pixel which is statically displayed. 640 32x32x32 tiles to be used for the map. The map is 8192x65536 (reduced later to 4096x65536, to lower the workload for the graphic artist). |
I will look into doing this, after releasing my current Amiga project (hopefully by the end of the month). |
np. Take your time. The Amiga time is already over since very long, so there's no need to hurry for this experiment. Quote:
Quote:
You don't need a full game: just a demo. I've created a ViewMap application to explore the maps on USA Racing, to quickly see how they looking and without firing up the game each time. You can do the same. |
Where can I get this app and data? |
Nowhere: it's mine, private. And it only works with the assets using my own format (the one used by another tool for creating maps etc.).
Anyway, the goal is to create a tool like that, but by using the OS. So, you don't need it.
And you need no asset as well: you can just draw a few tiles with numbers inside, for example, so that you can immediately use them. I was doing the same while waiting the assets from my graphic artist: I've drawn something myself and used it. Quote:
Quote:
Of course, entirely using the OS. |
Just to be clear, we are talking about 'hybrid' mode, where the game accesses hardware directly but the OS is not killed. That's not the same as 'entirely using the OS'. |
Sure, but pay attention: no dirty tricks. You should use only things / API allowed by the OS / Commodore guidelines. Quote:
Quote:
And it'd be good to have the first time it using the regular APIs, so without resorting to a custom View with the custom/user copper list doing all the work. |
'Custom' and 'user' are not the same thing. A 'user' copper list is merged into the system copper list so screen dragging etc. still works. This obviously has some limitations. |
Exactly. And that's the only thing that you can have, when using the OS. Quote:
A 'custom' copper list replaces the system copper list, and then you can do anything. |
There's nothing like that. More infos below. Quote:
Strictly speaking you don't have to create a custom view, because you can obtain the actual copperlist from graphics base (gb_LOFList points to it) and then poke it to eg. change the bitmap addresses. But that's hacky, and the system will restore the original copper list when it feels like it (which might be when your game is running). |
Exactly. It's a dirty hack, whereas the goal is use only what the OS allows you. Quote:
The proper method is to do LoadView(NULL), then the system thinks there's no display so you can create your own copper list and use it without interference - without having to kill the OS. |
That's a completely wrong interpretation of what LoadView does and, in general, what the OS allows you to do.
First of all, passing NULL means only that the system stops doing anything, because there's no view to process. In fact, it leaves everything like it is, and the display and sprites can still be active (that's why the Libraries & Devices manual suggest to use the respective macros to turn them off).
Second, and more important, loading a NULL View does NOT automatically give you the permission to directly use the Copper and feed it with what you want. This API, as I've said, simply tells the system to process no views anymore. In fact, there's not a single statement in the manual that says that you're entitled to take over the Copper and the display controller, in general, after having done it.
Third, the same manual states that there are only two possibilities to display something: either you create a screen with the proper Intuition API, or create a view via the proper graphics.library API. There is no "third way" which gives you the (full) control of the display subsystem.
In fact, and forth, there's no display.resource to acquire and use, for example. As well as there are no APIs like OwnCopper, WaitCopper, DisownCopper. So, the only way to access the Copper is via the proper View, ViewPort, etc., and the user copperlists, which are created using the proper macros that the OS/SDK gives you.
In short: you cannot control / use the Copper as you want by using LoadView(NULL): you've to create a normal View and deal with it.
BTW, even using the Blitter has limits. The same manual clearly states that the Blitter is heavily used by the system, so if you decide to directly use it, then you've to: - own it; - wait for being ready; - program and start your operation; - disown it.
Otherwise the suggestion is to use the proper queues and their related APIs.
Needless to say, all this has an heavy impact on performances, since you cannot use tricks like preloading the Blitter registers with common values which can be shared for multiple consecutive blits.
Last but not really least, using the OS you need to properly define the assets allocation. Which isn't trivial, since you've no idea of what the systems could give in terms of: largest block of Chip/Other RAM, and list of other blocks that could be used for the other assets. That's the most important factor when you need to define what the game should use.
|
| Status: Offline |
| | pixie
 |  |
Re: Directly programming the Amiga hardware was not a bad practice! Posted on 24-Oct-2024 21:18:44
| | [ #44 ] |
| |
 |
Elite Member  |
Joined: 10-Mar-2003 Posts: 3412
From: Figueira da Foz - Portugal | | |
|
| | Status: Offline |
| | bhabbott
|  |
Re: Directly programming the Amiga hardware was not a bad practice! Posted on 25-Oct-2024 3:58:57
| | [ #45 ] |
| |
 |
Cult Member  |
Joined: 6-Jun-2018 Posts: 509
From: Aotearoa | | |
|
| @cdimauro
Quote:
cdimauro wrote: @bhabbott
Quote:
The proper method is to do LoadView(NULL), then the system thinks there's no display so you can create your own copper list and use it without interference - without having to kill the OS. |
That's a completely wrong interpretation of what LoadView does and, in general, what the OS allows you to do.
First of all, passing NULL means only that the system stops doing anything, because there's no view to process. In fact, it leaves everything like it is, and the display and sprites can still be active (that's why the Libraries & Devices manual suggest to use the respective macros to turn them off).
Second, and more important, loading a NULL View does NOT automatically give you the permission to directly use the Copper and feed it with what you want. This API, as I've said, simply tells the system to process no views anymore. In fact, there's not a single statement in the manual that says that you're entitled to take over the Copper and the display controller, in general, after having done it.
Third, the same manual states that there are only two possibilities to display something: either you create a screen with the proper Intuition API, or create a view via the proper graphics.library API. There is no "third way" which gives you the (full) control of the display subsystem.
In fact, and forth, there's no display.resource to acquire and use, for example. As well as there are no APIs like OwnCopper, WaitCopper, DisownCopper. So, the only way to access the Copper is via the proper View, ViewPort, etc., and the user copperlists, which are created using the proper macros that the OS/SDK gives you.
In short: you cannot control / use the Copper as you want by using LoadView(NULL): you've to create a normal View and deal with it.
|
From NDK 3.1
Quote:
OS Game Techniques ==================
(c) Copyright 1992-93 Commodore-Amiga, Inc. All Rights Reserved ...
Hardware resources: ...
2) Copper. If you really have to take over the copper, get the LoadView(NULL), do 2 WaitTOF()s, and then install your own copperlists in the cop1/2jmp registers....
temp=GfxBase->ActiView; LoadView(NULL); WaitTOF(); WaitTOF(); /* custom.cop1lc = ??? */
...
WaitTOF(); WaitTOF(); LoadView(temp); custom.cop1lc=GfxBase->copinit;
|
|
| Status: Offline |
| | cdimauro
|  |
Re: Directly programming the Amiga hardware was not a bad practice! Posted on 25-Oct-2024 4:30:12
| | [ #46 ] |
| |
 |
Elite Member  |
Joined: 29-Oct-2012 Posts: 4127
From: Germany | | |
|
| @pixie
Quote:
Yes, I know it. The guy is also writing posts on the Commodore Amiga FB group, giving updates on his project.
Thanks for sharing, anyway. 
@bhabbott
Quote:
bhabbott wrote: @cdimauro
Quote:
cdimauro wrote: @bhabbott
[quote]The proper method is to do LoadView(NULL), then the system thinks there's no display so you can create your own copper list and use it without interference - without having to kill the OS. |
That's a completely wrong interpretation of what LoadView does and, in general, what the OS allows you to do.
First of all, passing NULL means only that the system stops doing anything, because there's no view to process. In fact, it leaves everything like it is, and the display and sprites can still be active (that's why the Libraries & Devices manual suggest to use the respective macros to turn them off).
Second, and more important, loading a NULL View does NOT automatically give you the permission to directly use the Copper and feed it with what you want. This API, as I've said, simply tells the system to process no views anymore. In fact, there's not a single statement in the manual that says that you're entitled to take over the Copper and the display controller, in general, after having done it.
Third, the same manual states that there are only two possibilities to display something: either you create a screen with the proper Intuition API, or create a view via the proper graphics.library API. There is no "third way" which gives you the (full) control of the display subsystem.
In fact, and forth, there's no display.resource to acquire and use, for example. As well as there are no APIs like OwnCopper, WaitCopper, DisownCopper. So, the only way to access the Copper is via the proper View, ViewPort, etc., and the user copperlists, which are created using the proper macros that the OS/SDK gives you.
In short: you cannot control / use the Copper as you want by using LoadView(NULL): you've to create a normal View and deal with it.
|
From NDK 3.1
Quote:
OS Game Techniques ==================
(c) Copyright 1992-93 Commodore-Amiga, Inc. All Rights Reserved ...
Hardware resources: ...
2) Copper. If you really have to take over the copper, get the LoadView(NULL), do 2 WaitTOF()s, and then install your own copperlists in the cop1/2jmp registers....
temp=GfxBase->ActiView; LoadView(NULL); WaitTOF(); WaitTOF(); /* custom.cop1lc = ??? */
...
WaitTOF(); WaitTOF(); LoadView(temp); custom.cop1lc=GfxBase->copinit;
|
OK. That's a new thing for me.
I've never read anything like that from the Amiga Reference Manual series. |
| Status: Offline |
| | Joe_RSA
|  |
Re: Directly programming the Amiga hardware was not a bad practice! Posted on 25-Oct-2024 7:25:40
| | [ #47 ] |
| |
 |
Member  |
Joined: 26-Oct-2018 Posts: 10
From: Unknown | | |
|
| @cdimauro
Directly programming hardware has its pro's and con's. Sometimes by accessing the hardware direct it's much faster and is not bad practice. You just need to know what you doing. |
| Status: Offline |
| | Karlos
|  |
Re: Directly programming the Amiga hardware was not a bad practice! Posted on 25-Oct-2024 21:18:49
| | [ #48 ] |
| |
 |
Elite Member  |
Joined: 24-Aug-2003 Posts: 4843
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition! | | |
|
| Just another vote for "it all depends on what you are doing and why". If you want to write a system friendly application that works across OS versions and models you generally stick to system provided means and maybe even have to abstract those to some extent to work around differences.
If you just want to bang the hardware because there's this insane idea bursting to get out of your mind and into the silicon, then go for it. Who cares if it doesn't run elsewhere then?
These approaches just sit at opposite ends of a spectrum of things you can do.
Metal banging becomes bad practise when you don't intend for your code to be coupled to the hardware it's programming or you rely on undocumented behaviour. _________________ Doing stupid things for fun... |
| Status: Offline |
| | cdimauro
|  |
Re: Directly programming the Amiga hardware was not a bad practice! Posted on 26-Oct-2024 5:01:55
| | [ #49 ] |
| |
 |
Elite Member  |
Joined: 29-Oct-2012 Posts: 4127
From: Germany | | |
|
| @Joe_RSA
Quote:
Joe_RSA wrote: @cdimauro
Directly programming hardware has its pro's and con's. Sometimes by accessing the hardware direct it's much faster and is not bad practice. You just need to know what you doing. |
Exactly. I've enjoyed both writing OS-friendly applications and directly accessing the hardware. The important thing is following the rules.
However, the main problem is that those rules were changed over the time, and even drastically. The above LoadView(NULL) is a clear example: it arrived only with the NDK 3.1 (released on November 1993: Commodore went in bankrupt on April 1994!), completely contradicting the previous documentation. And it was too late, anyway: it was when Commodore was pushing for just use the OS even for games. In fact:
If you really have to take over the copper, get the LoadView(NULL), do 2 WaitTOF()s, and then install your own copperlists in the cop1/2jmp registers. I do not recommend this though. Future chipsets may have faster and more efficient coppers with 32 bits, and we will want to use these. If you load the old copper registers behind graphics' back, we have no way of switching back to the old 16-bit mode.
which speaks by itself.
It would have helped at the very beginning, when there were little resources available, but certainly not at the end of 1993...
|
| Status: Offline |
| | cdimauro
|  |
Re: Directly programming the Amiga hardware was not a bad practice! Posted on 26-Oct-2024 5:07:47
| | [ #50 ] |
| |
 |
Elite Member  |
Joined: 29-Oct-2012 Posts: 4127
From: Germany | | |
|
| @Karlos
Quote:
Karlos wrote: Just another vote for "it all depends on what you are doing and why". If you want to write a system friendly application that works across OS versions and models you generally stick to system provided means and maybe even have to abstract those to some extent to work around differences. |
Well, "abstracting" and "Amiga OS" aren't so much compatible words.
The OS is very tailored to the hardware and didn't provide that much high-level APIs, forcing you to use the drivers/devices many times, which is something that normally applications don't or even can't do on other systems. Quote:
If you just want to bang the hardware because there's this insane idea bursting to get out of your mind and into the silicon, then go for it. |
No, it's not like that. In fact, it's all about what you need to do and the constraints that you've.
As I've tried to explain before, memory management is a big problem if you want to use the OS: there's nothing that could guarantee you what to get once the your code is loaded in memory. How much is the biggest chunk of memory? How about the remaining chunks? If you've to define the assets for your game and also for the screen(s) that you need to use, you've no clue on what you can have and where to map them.
Having 512kB of Chip RAM and 512kB of "other" mem is a big problem to deal with for developers, because of that. The 2MB of Chip RAM which came with the AGA where much better, because you've much more freedom from this PoV, and you can safely say: "I consider 200kB less of the overall total, and the rest can be safe to use for the assets".
Performance... here there's another problem. A 7Mhz 68000 isn't so much fast, and you've to push as much possible towards the Blitter. Which, using the OS, was much slower because of the protocol to be followed, which introduces a big overhead. And if you also have to push the processor as well... that's another big problem, because you need to disable the interrupts (not for so long, as per Commodore guidelines) to take full advantage of it, and then enable them again, and so son. Which is another big overhead. Whereas the 68EC02 of the Amiga 1200 was a piece of cake, even with its castrated access to the Chip RAM (thanks, Amiga engineers!). Quote:
Who cares if it doesn't run elsewhere then? |
It's possible to write code which directly access the hardware AND which works everywhere: "just" (!) follow the rules... Quote:
These approaches just sit at opposite ends of a spectrum of things you can do. |
I wouldn't say so. As usual, it depends on what you need to do: it's the project's requirements that tells you what way to follow. Quote:
Metal banging becomes bad practise when you don't intend for your code to be coupled to the hardware it's programming |
No, it's all about not following the guidelines or not.
Following -> good practice. Not following -> bad practice.
It's a boolean thing, which is applied everywhere: either by using the OS or directly accessing the hardware. Quote:
or you rely on undocumented behaviour. |
Which is part of the above bad practices. |
| Status: Offline |
| | NutsAboutAmiga
|  |
Re: Directly programming the Amiga hardware was not a bad practice! Posted on 26-Oct-2024 9:38:25
| | [ #51 ] |
| |
 |
Elite Member  |
Joined: 9-Jun-2004 Posts: 12960
From: Norway | | |
|
| @Joe_RSA
I think a lot of problems, we have with old software is due fact developers quick to push software to market, and where not focused on making the game or program work in future, perhaps they where thinking can go back and fix it later, he he…. Yeh right that almost never happens.
Not doing your best, the first time, I think is an example of a bad programmer, everyone was making the same mistakes and learning to code back then.
Also think deciding to bang the hardware or not, was simply down to skills they had, if know to bang the hardware, you perhaps did not best practices for writing OS friendly program or game, or perhaps if good with the OS, you did not know to bang the hardware. So, people did what they know how to.
Not every card game or sudoku, chess, Tetris, turn based strategy, adventure game, do you really need to max out your 7Mhz / OCS machine. Most definitely a lot of games that, should not have banged the hardware.
I can’t think of any case where I think this OS friendly game, should have banged the hardware.
A lot of games use 2 different resolutions on the screen, and lot used different colors on the HUD and the game area, but with true colors graphics, and higher resolution, you don’t need to split things up like that.
I think it made sense at time, but with hardware upgrades, it almost never makes sense. Last edited by NutsAboutAmiga on 26-Oct-2024 at 06:46 PM. Last edited by NutsAboutAmiga on 26-Oct-2024 at 09:40 AM.
_________________ http://lifeofliveforit.blogspot.no/ Facebook::LiveForIt Software for AmigaOS |
| Status: Offline |
| | Karlos
|  |
Re: Directly programming the Amiga hardware was not a bad practice! Posted on 26-Oct-2024 10:21:17
| | [ #52 ] |
| |
 |
Elite Member  |
Joined: 24-Aug-2003 Posts: 4843
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition! | | |
|
| @cdimauro
I appreciate your original argument is from a historical perspective, but I'm talking about the situation today. It's totally fine to write metal banging hardware dependent code if you want because almost nobody is working on commercial software where portability matters, you are just doing something for the fun of it. If you are working on software that supposed to be portable among different hardware configurations then you will need to care to program to more towards API than to HW, except where your HW is universal. And you can do both, it doesn't take much, for example, to encapsulate all your drawing requirements into a substitutable set of functions that may efficiently hit the metal on one configuration and talk to the RTG on another. This is she sort of abstraction you make in your code, since some of the existing OS abstraction you might want either doesn't exist, or is too slow for your needs. Last edited by Karlos on 26-Oct-2024 at 10:24 AM. Last edited by Karlos on 26-Oct-2024 at 10:23 AM.
_________________ Doing stupid things for fun... |
| Status: Offline |
| | ppcamiga1
|  |
Re: Directly programming the Amiga hardware was not a bad practice! Posted on 26-Oct-2024 18:18:06
| | [ #53 ] |
| |
 |
Cult Member  |
Joined: 23-Aug-2015 Posts: 985
From: Unknown | | |
|
| Directly programming the Amiga hardware was good idea when there was one Amiga hardware it was unique and fast. Which means Amiga 500 times up to june 1992. Amiga 500 has nice fast cpu nice fast graphics. hardware hitting is still good idea when target is Amiga with 68000 7 MHz OCS 0.5 MB RAM CHIP 0.5 MB RAM other. good old way of programming Amiga like in good old days of golden era of Amiga 500. If target is everything never it should be done by OS. Or at least some software layer should be added (custom device? custom library?). to save time and work.
|
| Status: Offline |
| | ppcamiga1
|  |
Re: Directly programming the Amiga hardware was not a bad practice! Posted on 26-Oct-2024 18:20:57
| | [ #54 ] |
| |
 |
Cult Member  |
Joined: 23-Aug-2015 Posts: 985
From: Unknown | | |
|
| what Karlos wrote is pure pistorm propaganda BS. software for everything never than Amiga 500 should use os. that is easier to program, easier to debug, takes less time and work.
|
| Status: Offline |
| | Karlos
|  |
Re: Directly programming the Amiga hardware was not a bad practice! Posted on 26-Oct-2024 18:52:45
| | [ #55 ] |
| |
 |
Elite Member  |
Joined: 24-Aug-2003 Posts: 4843
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition! | | |
|
| @ppcamiga1
WTAF are you blathering on about this time? Hobbyist Amiga Devs can do whatever they want with their machines, no matter how bad and dirty since the risk is all theirs. Absolute end of story.
If you want your software to work on more than just your own machine (or another with the exact same configuration) then you have to play by the rules and the more portable you want it, the more your desire to hit the hardware needs to be tempered in favour of using software APIs instead.
Is that simple enough, or shall I get the crayons out? _________________ Doing stupid things for fun... |
| Status: Offline |
| | NutsAboutAmiga
|  |
Re: Directly programming the Amiga hardware was not a bad practice! Posted on 26-Oct-2024 19:48:03
| | [ #56 ] |
| |
 |
Elite Member  |
Joined: 9-Jun-2004 Posts: 12960
From: Norway | | |
|
| @ppcamiga1
What I learned is you can’t, change anyone’s mind, if they are set on banging the hardware they are going to, and actually if you push really hard you just get banned, or disliked, so when I started working on my hardware emulation projects, this was pretty much the case. peaple do not like being told they are wrong, even if you try to be nice and constructive, by telling peaple there is better way to do something.
When people had questions on how to do something, I normally posted link to how to do it system friendly.
Even when I talked about retroMode.library. People did not like that you do planar effects on RTG library.
Future Crew - Second Reality (1993) was a real shock to the Amiga community. People can’t believe it was not an Amiga demo.
https://www.youtube.com/watch?v=iw17c70uJes Last edited by NutsAboutAmiga on 26-Oct-2024 at 08:06 PM. Last edited by NutsAboutAmiga on 26-Oct-2024 at 08:04 PM. Last edited by NutsAboutAmiga on 26-Oct-2024 at 08:01 PM.
_________________ http://lifeofliveforit.blogspot.no/ Facebook::LiveForIt Software for AmigaOS |
| Status: Offline |
| | Hammer
 |  |
Re: Directly programming the Amiga hardware was not a bad practice! Posted on 27-Oct-2024 2:28:55
| | [ #57 ] |
| |
 |
Elite Member  |
Joined: 9-Mar-2003 Posts: 6171
From: Australia | | |
|
| @cdimauro
Quote:
cdimauro wrote: 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/
|
It's bad practice when hit-the-metal PS4 imposes heavier evolution limitations for PS4 Pro and PS5.
PS4 Pro's GPU's 36 CU GCN Polaris+ degrades into PS4's 18 CU GCN 2.0 mode.
36 CU is direct 2X over 18 CU._________________ Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68) Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68) Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB |
| Status: Offline |
| | cdimauro
|  |
Re: Directly programming the Amiga hardware was not a bad practice! Posted on 27-Oct-2024 4:58:02
| | [ #58 ] |
| |
 |
Elite Member  |
Joined: 29-Oct-2012 Posts: 4127
From: Germany | | |
|
| @NutsAboutAmiga
Quote:
NutsAboutAmiga wrote: @Joe_RSA
I think a lot of problems, we have with old software is due fact developers quick to push software to market, and where not focused on making the game or program work in future, perhaps they where thinking can go back and fix it later, he he…. Yeh right that almost never happens.
Not doing your best, the first time, I think is an example of a bad programmer, everyone was making the same mistakes and learning to code back then. |
Again, that's not the case. The only relevant thing is weather the guidelines were followed or not.
I PERSONALLY think that the OS should have been tried first, but that's only MY OPINION.
What matters when you judge a programmer is and remains only one thing: guidelines followed -> good, not followed -> bad. End of discussions... Quote:
Also think deciding to bang the hardware or not, was simply down to skills they had, if know to bang the hardware, you perhaps did not best practices for writing OS friendly program or game, or perhaps if good with the OS, you did not know to bang the hardware. So, people did what they know how to. |
And that's not a problem regarding the dispute.
It's a pity if someone had not enough knowledge to at least try the different approach / solution, but at the end it's only his/her ignorance here. Quote:
Not every card game or sudoku, chess, Tetris, turn based strategy, adventure game, do you really need to max out your 7Mhz / OCS machine. Most definitely a lot of games that, should not have banged the hardware. |
Should have not -> YOUR opinion.
As long as they followed the guidelines, I don't see anything wrong.
Despite I agree that in those case they could have used the OS, instead. But that's another thing, and it's just my opinion. Quote:
I can’t think of any case where I think this OS friendly game, should have banged the hardware. |
With turn based strategy games it could have been a possibility, if you've to move a lot of characters / graphics in the screen (Blitter performance issues), and you had several assets (memory allocation issues. Maybe also CPU performance issues if you need to transfer the assets from the Other RAM to the Chip RAM). Quote:
A lot of games use 2 different resolutions on the screen, |
No, almost all games used the same resolution. It's rare to see games that used lores (the standard) and hires/shires at the same time. Quote:
and lot used different colors on the HUD and the game area, |
Yes, but what's the problem here? Quote:
but with true colors graphics, and higher resolution, you don’t need to split things up like that. |
I reveal a secret: that was not even a dream at the Amiga time, because we had... what we had.
All this stuff came in 90s. I mean: on the mainstream market. Quote:
I think it made sense at time, but with hardware upgrades, it almost never makes sense. |
Yes, but what's the problem? As long as the rules are followed, the old games could run on the future machines with much better hardware.
And even using the OS, games cannot take advantage of higher resolutions and true colour graphics, as well as 16-bit CD quality audio channels, multiple audio channels, etc., because the assets are already defined and the game uses that ones.
Only 3D games might have taken the chance to use higher resolutions, but there were no Monitor concept at the Amiga time and how to select the screen to use.
For those enhancements you need to rewrite the game, even partially, and of course you need the new assets. Which is something which happens even in the modern age: they are collect Remastered editions. Because you cannot take Resident Evil, for example, and pretend to use 4K, HDR, high-resolution textures, etc. etc. without touching a single line of its code... |
| Status: Offline |
| | cdimauro
|  |
Re: Directly programming the Amiga hardware was not a bad practice! Posted on 27-Oct-2024 5:00:09
| | [ #59 ] |
| |
 |
Elite Member  |
Joined: 29-Oct-2012 Posts: 4127
From: Germany | | |
|
| @Karlos
Quote:
Karlos wrote: @cdimauro
I appreciate your original argument is from a historical perspective, but I'm talking about the situation today. It's totally fine to write metal banging hardware dependent code if you want because almost nobody is working on commercial software where portability matters, you are just doing something for the fun of it. If you are working on software that supposed to be portable among different hardware configurations then you will need to care to program to more towards API than to HW, except where your HW is universal. And you can do both, it doesn't take much, for example, to encapsulate all your drawing requirements into a substitutable set of functions that may efficiently hit the metal on one configuration and talk to the RTG on another. This is she sort of abstraction you make in your code, since some of the existing OS abstraction you might want either doesn't exist, or is too slow for your needs. |
Exactly, and I've absolutely no problem with that: nowadays we've completely different development models, which are already established since around 3 decades.
I even use Python instead of assembly almost all of my time, even when dealing with low-level stuff. |
| Status: Offline |
| | cdimauro
|  |
Re: Directly programming the Amiga hardware was not a bad practice! Posted on 27-Oct-2024 5:04:27
| | [ #60 ] |
| |
 |
Elite Member  |
Joined: 29-Oct-2012 Posts: 4127
From: Germany | | |
|
| @NutsAboutAmiga
Quote:
NutsAboutAmiga wrote: @ppcamiga1
What I learned is you can’t, change anyone’s mind, if they are set on banging the hardware they are going to, and actually if you push really hard you just get banned, or disliked, so when I started working on my hardware emulation projects, this was pretty much the case. peaple do not like being told they are wrong, even if you try to be nice and constructive, by telling peaple there is better way to do something. |
They don't like it because they weren't wrong: directly hitting the hardware doesn't automatically mean that someone is doing the wrong thing. That's YOUR, PERSONAL, WRONG (yes!) opinion.
As I've already said multiple times, what matter is all about following the guidelines or not. You don't follow them -> you're wrong. You follow them -> you're right. That's a very simple, boolean thing to understand: when do you think that it will be time to take it? |
| Status: Offline |
| |
|
|
|
[ home ][ about us ][ privacy ]
[ forums ][ classifieds ]
[ links ][ news archive ]
[ link to us ][ user account ]
|