@amigang

Quote:

amigang wrote: 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.

Yes, for the first games, but most of games directly accessed the hardware, even if they were multiplatform.
Quote:

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.

There was the Amiga Hardware Reference Manual, which was available early, especially for software houses.
Quote:

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.

Unfortunately, no: developers spent A LOT of time on optimizations. Not all developers, because there was also the time-to-market which was forced by the software house.

@Hypex

Quote:

Hypex wrote: @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.

Much, much less: it's enough to take a look at some Protracker player to spot the huge difference.
Quote:

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.

Exactly. That's something which I'll talk in some other article which focus on the missing parts of the Amiga OS for game development purposes.
Quote:

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.

That's difficult to find now. Especially on this forum, and with you having written more than 11 thousand comments it would be a big challenge.
Quote:

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...

The Amiga 1000 was more like a personal computer. Even a small workstation. But certainly not a home computer like a C64.
Quote:

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.

I can't judge, because it's a too generic description.

I can tell you that I've used the Blitter to generate the parallax scrolling of the floor (like Street Fighter II), because it was easier to achieve (BTW: it never went into production), but using the hardware scrolling was another possibility by complicating (a lot!) the code to rendere the two characters. But I've also extensive used the sprites and other Amiga features (hardware scrolling, of course).
Quote:

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.

No, we didn't redraw the entire screen each time, using the Blitter.

The Amiga way was to update only part of the graphic: what was enough to achieve the goal.

Which is completely different from what is done now (and since around 3 decades).

@cdimauro

I keep talking about my own stuff/projects, but there are other interesting projects being worked on by others.

ACE is a game engine, the aim is program the hardware in C, and as I understand it, provided library api, and possibly support multiple hardware configurations and targets, similar to how SDL works, just for Amiga computers.

Scorpion engine, what is interesting about it, is that uses true color, and does color reduction, due decline in old school pixel artists, this allows people who are not familiar with Amiga to make games, using Windows. Because engine uses higher quality image, it should be possible to support true color capable Amiga systems as well, like Vampire or AmigaONE, perhaps the A600GS with ARM graphics library, but currently I do not think that’s the case.

downscaling, and color reduction techniques are definitely cool to have in a game engine, this means you have one set of data files for everything, you can for exsample generate temporary assets to reduce loading time, for lower spec hardware.

Last edited by NutsAboutAmiga on 22-Oct-2024 at 08:03 PM.

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

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: 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,

That's very small compared to what we gained in terms of available resources / computing power.

4K for gaming is quite common (albeit more common is still FullHD) now, whereas at the Amiga time it was 320x200.
So, we have 8.3M vs 64k pixels (which means that we've a factor of 130). Whereas GPUs nowadays process thousands of GPixel/s...
Quote:

720p is pretty much the standard people use on workbench these days.

It's at least FullHD, with plenty of people have 1440p and 4k.

720p could be still be used, but mostly for retro machines.
Quote:

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.

Their problem is that they also don't full support / makes use of all GPU resources.
Quote:

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.

I don't get what was the problem that you wanted to solve. Any detail / example?
Quote:

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.

That's something which shouldn't be needed on modern computers: you should have enough computational power to completely redraw the screen several times, and without noticing artifacts / slowdowns.

I mean: we're talking about UAE = Amiga emulation = mostly low-resolution 2D graphics...
Quote:

There is big difference between DDR2 and DDR3 memory no doubt.

Imagine now that we've DDR5 and the new "DIMM" format...
Quote:

Perhaps what is true for X1000 is not true for X5000, something to keep in mind when optimizing.

Absolutely: their processors are different and need different optimizations to squeeze the most from each one.

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @cdimauro I keep talking about my own stuff/projects, but there are other interesting projects being worked on by others. ACE is a game engine, the aim is program the hardware in C, and as I understand it, provided library api, and possibly support multiple hardware configurations and targets, similar to how SDL works, just for Amiga computers. Scorpion engine, what is interesting about it, is that uses true color, and does color reduction, due decline in old school pixel artists, this allows people are not familiar with Amiga to make games, using Windows. Because engine uses higher quality image, it should be possible to support true color capable Amiga systems as well, like Vampire or AmigaONE, perhaps the A600GS with ARM graphics library, but currently I do not think that’s the case. downscaling, and color reduction techniques are definitely cool to have in game engine, this means you have one set of data files for everything, you can for exsample generate temporary assets to reduce loading time, for lower spec hardware.

I've absolutely nothing against such programs/tools.

However, those were not available at the time, and probably not suitable for creating the very good games which we know very well.

In short: it's too late. The market was already gone in the second half of the '90s.

@cdimauro

Quote:

cdimauro wrote: 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.

So not serious then...

Quote:

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.

I suspected this would be part of your argument. However this isn't proof that these games couldn't have been made using the OS, just that they would have to be changed in some way to work on a stock 1MB A500. You could say that any such 'compromise' would be unacceptable, but this is not reasonable. Why not?

1. If less memory was available you would have made the game work with that smaller amount, probably with no noticeable degradation. You used the maximum amount of memory you could for the same reason George Mallory climbed Mount Everest - 'because it's there' (If it wasn't he might have lived a lot longer!).

2. The main reason for using the OS is to take advantage of its features. This may include:-
- Loading from different media such as a hard drive or CD-ROM.
- Multi-player over a network.
- Running on 'non-standard' machines such as an A500 with 512k ChipRAM and non-autoconfiguring FastRAM.
- Multitasking on machines which have the resources to do it.
- handling hardware differences in future machines or that you don't know about.

By insisting on making the game the 'best it can possibly be' on a 1MB A500, you lose those other things that using the OS could provide. You may say "So what? There are enough 1MB A500 users that I don't need to pander to the rest". But this is the same reason PC developers gave for not supporting the Amiga, which ultimately led to its demise. When the 'best' games won't take advantage of hardware upgrades, people won't buy those upgrades - making it harder for games to get better and harder for the platform to survive.

I notice that Fightin' Spirit came on 5 disks. I'm curious to know how you handled that when the OS has been kicked out. Unfortunately you won't let us see the source code, and I can't be bothered disassembling the program right now, so I can can only ask:-

Did you have custom floppy disk loading routines? If so this must have taken up some memory, right?

Was the data on the disks 'crunched' to save space (requiring more memory and CPU time to 'decrunch'). How hard was it to minimize the number of disks needed without impacting performance?

One reason I ask is that a lot of Amiga games suffer from annoyingly slow loading times between levels or when you die etc. Being able to install the game on a hard drive would fix that, but if you kick out the OS the user doesn't have that option. Some games won't even use extra floppy drives, requiring much onerous disk swapping. It could be argued that the frustration of slow loading times cancels the slight improvement achieved by kicking out the OS to get more memory.

I also notice that you made a CD32 version of Fightin' Spirit. AFAIK it's not possible to load from the CD-ROM drive without the OS being present unless you develop custom code to do it, which is very difficult when the hardware isn't documented. So this means the game isn't 'the best it could possibly be' on the CD32, right?

Quote:

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.

I was thinking more of some technique that wasn't possible if the OS was present. If memory is the only concern then I guess any game that didn't need all of it could be made to work in 'hybrid mode', right?

Quote:

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.

This shouldn't be a concern when using 'hybrid' mode. Commodore themselves documented how to take over the screen display in a system-friendly way, allowing you to use custom copper lists directly without killing the OS or doing 'illegal' pokes.

Quote:

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.

But USA Racing was never released, right? I don't think it's fair to reference a game which wasn't released as proof that some games couldn't be OS friendly.

@cdimauro

Quote:

cdimauro wrote: @NutsAboutAmiga I've absolutely nothing against such programs/tools. However, those were not available at the time, and probably not suitable for creating the very good games which we know very well. In short: it's too late. The market was already gone in the second half of the '90s.

I agree with this. And since we are talking about stock A500's, anything that wasn't available before 1992 is irrelevant to this thread.

The A1200 opened up a world of possibilities that made game programming much easier, including more memory, faster CPU, better graphics hardware, stock hard drive (in 'HD' machines), and a more efficient OS. But it was also too late to save the platform, as well as requiring a shift in attitude towards being more OS friendly.

@NutsAboutAmiga

there were even game related shared libs in late 90s that support games, even one that made it possible to develop a game that works everywhere without change (ECS, AGA, RTG) and fully use it. But it was hardly used. It was game over already. And you need specific amiga games for it. A cross-platform engine that not only supports amiga platforms but also modern platforms and makes development easy, or at least a class-library supporting that, did not exist

@OlafS25

rtgmaster.library was one of this early attempts.
It was an interesting library, it was not hugely popular,

Its interesting that support EGS, however, not many use that graphic system.

I believe it has some alignment issues on AmigaOS4.x, also early programs,
used a lot fixed sized resolutions, and hardcoded mode id’s, typical more then one problem.
It can be simply the wrong use of the library, or some other boundary bugs.

Any case, RTGMaster is wrapper for CGX, and CGX is wrapper for P96, and from OS4.1 Final edition, P96 is wrapper for graphics.library AmigaOS4. There multiple layers of wrappers, not a good idea.

Last edited by NutsAboutAmiga on 23-Oct-2024 at 04:41 PM.
Last edited by NutsAboutAmiga on 23-Oct-2024 at 04:38 PM.

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

bhabbott Quote:

I suspected this would be part of your argument. However this isn't proof that these games couldn't have been made using the OS, just that they would have to be changed in some way to work on a stock 1MB A500. You could say that any such 'compromise' would be unacceptable, but this is not reasonable. Why not? 1. If less memory was available you would have made the game work with that smaller amount, probably with no noticeable degradation. You used the maximum amount of memory you could for the same reason George Mallory climbed Mount Everest - 'because it's there' (If it wasn't he might have lived a lot longer!).

There were Amiga games which needed the last 64kiB of memory and the AmigaOS likely fragmented at least that much memory. Taking over the system provided not only control but consistency thus avoiding out of memory error messages for some users with unpredictable configurations and add-on hardware. The majority of games likely did not use so much memory to make this necessary and many developers unnecessarily followed the leaders in the game industry that were pushing the envelope.

bhabbott Quote:

2. The main reason for using the OS is to take advantage of its features. This may include:- - Loading from different media such as a hard drive or CD-ROM. - Multi-player over a network. - Running on 'non-standard' machines such as an A500 with 512k ChipRAM and non-autoconfiguring FastRAM. - Multitasking on machines which have the resources to do it. - handling hardware differences in future machines or that you don't know about. By insisting on making the game the 'best it can possibly be' on a 1MB A500, you lose those other things that using the OS could provide. You may say "So what? There are enough 1MB A500 users that I don't need to pander to the rest". But this is the same reason PC developers gave for not supporting the Amiga, which ultimately led to its demise. When the 'best' games won't take advantage of hardware upgrades, people won't buy those upgrades - making it harder for games to get better and harder for the platform to survive.

I agree with your strong arguments for retaining the AmigaOS. It was better for games to provide enhancements when more memory or hardware was available than to squeeze out the last drop of a standard hardware configuration. Some games provided enhancements with upgraded hardware like enhanced sound and decreased loading times, the latter of which was possible with the AmigaOS by adding disk buffers, adding a floppy disk or adding a hard disk. Some games opted for requiring more memory like Dungeon Master which was partially responsible for pushing the standard 1 MiB Amiga configuration and included bundles with the memory upgrade.

https://www.filfre.net/2015/12/dungeon-master-part-1-the-making-of/ Quote:

But, soon enough, they got it, and ST owners lost their bragging rights again. FTL had designed their game engine to be portable from the beginning, and the Amiga, by far the computer most technically similar to the ST, was the obvious first target. The biggest stumbling block proved to be memory. The vast majority of Amigas out there at the time still had only 512 K, the same as the low-end ST for which Dungeon Master had originally been designed, but thanks to a more memory-hungry operating system FTL just couldn’t find a way to get the game running in that space. They made the painful decision to require a full 1 MB of memory, becoming the first prominent Amiga game to do so. The decision doubtless hurt sales to some extent, but such was Dungeon Master‘s burgeoning cult that it likely did just as much to drive sales of Amiga memory expansions. Just as Commodore’s own European subsidiaries had taken to packaging Amiga 500s with the latest hit games, at least one maker of RAM expansions, Tecno, acknowledged why their customers were really interested in their product by selling a sort of Dungeon Master playing kit that included the game in the same box as the memory expansion needed to play it. Many more games began to follow Dungeon Master‘s lead in demanding 1 MB, and by 1990 it had become the effective standard minimum. In return for their patience and their indulgence in expanded memory, Amiga owners were rewarded with bragging rights of their own over their ST rivals. While the graphics in the Amiga Dungeon Master remained unchanged, FTL had taken advantage of the Amiga’s superior sound hardware to enhance the experience: monsters moving about the rooms and corridors near your party were now heard in realistic stereo. Far from just a gimmick, the subtle stereo soundscape was a real boon to situational awareness, making Dungeon Master the first of the great headphone games.

PC clones pushed up hardware specs faster but the Amiga was a lower end market, initially with more performance, more memory, better graphics, better audio and better disk drive capacity. CBM didn't deem it necessary to maintain the integration advantage of the Amiga and all was lost.

The AmigaOS was thin only using 54 kiB of memory in Steve Shireman's boot from an PCMCIA SRAM drive example. This is likely similar to booting from a floppy but perhaps a little more memory is used for PCMCIA drive buffers even though the minimum likely could be used for a SRAM buffer. A 2nd floppy drive was one of the most common upgrades which you did not mention and which was problematic for games when not accompanied with a memory upgrade. As I recall, the default buffers for a disk drive are 5 and for a hard drive 30.

55,296 bytes (54 kiB) after boot from Amiga 1200 PCMCIA SRAM drive
floppy drive buffers: 5 x 512 = 2,560 bytes
PCMCIA drive buffers: 5 x 512 = 2,560 bytes
---
50,176 bytes for AmigaOS 3.x excluding buffers

Games that take over the system require disk buffers too although they can not so nicely limit the number of drives to save memory. The remaining AmigaOS memory I expect is mostly the expansion, exec, graphics, intuition, etc. libraries built in memory including the jump tables but excluding the code of the library in ROM. There would be a little more used by the multitasking overhead, expansion.library data and SetPatch/SetFunction() patches. The real problem with retaining the AmigaOS was inconsistency and unpredictability with growing jump tables of newer version libraries, memory needed by patches, user altered configurations and memory fragmentation. It wasn't a problem when memory was expanded where retaining the AmigaOS was the better option. There wasn't an easy option besides CBM increasing their Amiga standards including memory faster which you didn't think they should have done. Non-volatile flash memory ROM, the addition of a smaller (d32,PC) addressing mode for PC relative addressing and a new Amiga library standard could allow Amiga libraries to be available already built in flash ROM while allowing them to be patched thus reducing the building of libraries in memory. NOR flash was invented in 1984 and was first introduced by Intel in 1988 so wasn't too far off from being usable for Amiga ROMs to reduce memory and inconsistency in the memory available after boot.

bhabbott Quote:

I agree with this. And since we are talking about stock A500's, anything that wasn't available before 1992 is irrelevant to this thread. The A1200 opened up a world of possibilities that made game programming much easier, including more memory, faster CPU, better graphics hardware, stock hard drive (in 'HD' machines), and a more efficient OS. But it was also too late to save the platform, as well as requiring a shift in attitude towards being more OS friendly.

You want to retain the AmigaOS in games but not talk about enhancements and standards which would allow games to do it? The "stock" Amiga standard had improvements from 256 kiB to 512 kiB, to 1024 kiB and to 2048 kiB each of which made the argument to retain the AmigaOS stronger. You admit that major enhancements "opened up a world of possibilities" that made for a "a more efficient OS" and "requiring a shift in attitude towards being more OS friendly". Enhancements and better standards could have come much earlier like AA+ specs in 1989-1991 which likely would have saved the Amiga. CBM failed to innovate and integrate the Amiga at the same level and pace of Amiga Corporation or the competition. The other recent articles of cdimauro are Amiga what if articles so I don't see why you want to limit the topic.

Last edited by matthey on 23-Oct-2024 at 07:11 PM.
Last edited by matthey on 23-Oct-2024 at 04:55 PM.

@NutsAboutAmiga

RTGMaster was one of those... there were several

but propably not used often in reality

@NutsAboutAmiga

Quote:

Any case, RTGMaster is wrapper for CGX, and CGX is wrapper for P96, and from OS4.1 Final edition, P96 is wrapper for graphics.library AmigaOS4. There multiple layers of wrappers, not a good idea.

Odd I always was under the impression p96 was an wrapper for cybergraphx

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@bhabbott

Quote:

bhabbott wrote: @cdimauro Quote: cdimauro wrote: 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.

So not serious then... [/quote]
I was (and I'm) absolutely serious about my statements about the OS.

And source is NOT required / mandatory to be published.
Quote:

Quote: 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. I suspected this would be part of your argument.

Well, it's not my argument: those are FACTs.
Quote:

However this isn't proof that these games couldn't have been made using the OS, just that they would have to be changed in some way to work on a stock 1MB A500.

Which proves that the same game CANNOT be made with the OS...
Quote:

You could say that any such 'compromise' would be unacceptable, but this is not reasonable.

For you.
Quote:

Why not? 1. If less memory was available you would have made the game work with that smaller amount, probably with no noticeable degradation.

There's no "smaller" amount: there's no way to determine how much memory was available and usable for a game. You need to give a try when you're using the OS: it could work or not, and that's entirely depending on the specific machine. And you can't test n configurations for that.

As a developer, you should take a decision: you can only do a remarkable cut in the memory usage which you think that it might be enough, and then fingers crossing in the hope that it works.
Quote:

You used the maximum amount of memory you could for the same reason George Mallory climbed Mount Everest - 'because it's there' (If it wasn't he might have lived a lot longer!).

See above: at least without the OS I perfectly know how much memory was there and how can organize my code and assets.

With the OS you can have nothing like that, as I've already said (and not just now: it was already reported on my previous comments, but you didn't want to pay attention them).
Quote:

2. The main reason for using the OS is to take advantage of its features. This may include:- - Loading from different media such as a hard drive or CD-ROM.

Right.
Quote:

- Multi-player over a network.

Doable without the OS. Some games have done it. Stunt Car Racer, if I recall it right, should be a notable example.
Quote:

- Running on 'non-standard' machines such as an A500 with 512k ChipRAM and non-autoconfiguring FastRAM.

non-autoconfig RAM is crappy hack, which I don't care at all.
Quote:

Multitasking on machines which have the resources to do it.

Limited benefit: if you're playing a game... you're 100% focused on it.

Unless you're running a BBS in background, for example.
Quote:

- handling hardware differences in future machines or that you don't know about.

As long as the game is well written, it can run on any future machine.
Quote:

By insisting on making the game the 'best it can possibly be' on a 1MB A500, you lose those other things that using the OS could provide. You may say "So what?

Yes, that's what I say.
Quote:

There are enough 1MB A500 users that I don't need to pander to the rest".

Not exactly. There're a LIMITED RESOURCES for developing a game, and a software house which wants to... MAKE MONEY... out of it, then you've to focus on the most relevant configurations: Amigas which 512kB of Chip RAM, or with the additional 512kB expansion. Dot.

I repeat the concept: MAKING MONEY.
Quote:

But this is the same reason PC developers gave for not supporting the Amiga, which ultimately led to its demise.

Wrong: Amiga died because Commodore had too many incompetent people at all levels.
Quote:

When the 'best' games won't take advantage of hardware upgrades, people won't buy those upgrades - making it harder for games to get better and harder for the platform to survive.

It can be possibile only if there's enough customers. I repeat the concept: MAKING MONEY.

That's the reason why the 512kB expansion became the new standard with the Amiga: at a certain point in time the customer base was enough to justify the investments.
Quote:

I notice that Fightin' Spirit came on 5 disks. I'm curious to know how you handled that when the OS has been kicked out. Unfortunately you won't let us see the source code, and I can't be bothered disassembling the program right now, so I can can only ask:-

Well, as it happened for all games which kicked the OS out.
Quote:

Did you have custom floppy disk loading routines?

Of course.
Quote:

If so this must have taken up some memory, right?

Not so much. It should be around 1 kB or even less.

I don't know the final routine that Dario used for FS, but the source code for testing my custom track loader is 12.5kB ca, made up of around 550 lines in total (which includes the code to take control of the system, do the test, and going back to the OS).
Quote:

Was the data on the disks 'crunched' to save space (requiring more memory and CPU time to 'decrunch').

Yes. The graphic assets were compressed in 8-bit packed/chunky, because this way it was possible compress them much much more, compared to applying the same in bitplane format.
Quote:

How hard was it to minimize the number of disks needed without impacting performance?

I've no data, but the decompressing routine was quite fast even for a plain 7Mhz 68000.

Consider that reading an entire disk in memory takes around 36-37s. You can take it as a reference to see how much time is spent on doing other things.

However, you can always do other things while waiting for the MFM track to be read. For example... decoding & decompressing the previous MFM track...
Quote:

One reason I ask is that a lot of Amiga games suffer from annoyingly slow loading times between levels or when you die etc.

I know. As I've said before, you can improve the situation by parallelizing some activity, but it requires much more planning & development.
Quote:

Being able to install the game on a hard drive would fix that, but if you kick out the OS the user doesn't have that option. Some games won't even use extra floppy drives, requiring much onerous disk swapping. It could be argued that the frustration of slow loading times cancels the slight improvement achieved by kicking out the OS to get more memory.

You don't need only the OS + HD for that. As I've said before, you also need more memory.
Quote:

I also notice that you made a CD32 version of Fightin' Spirit. AFAIK it's not possible to load from the CD-ROM drive without the OS being present unless you develop custom code to do it, which is very difficult when the hardware isn't documented. So this means the game isn't 'the best it could possibly be' on the CD32, right?

Well, FS for CD32 was a port of the OCS version, which used 1MB. The CD32 had 2MB: there's plenty of extra, free space to keep the OS alive. AND the processor is much, much faster than.

So, you have no memory neither performance issues...
Quote:

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.

I was thinking more of some technique that wasn't possible if the OS was present. If memory is the only concern then I guess any game that didn't need all of it could be made to work in 'hybrid mode', right? [/quote]
Performance is another problem...
Quote:

Quote: 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. This shouldn't be a concern when using 'hybrid' mode. Commodore themselves documented how to take over the screen display in a system-friendly way, allowing you to use custom copper lists directly without killing the OS

The custom/user copper list works only AFTER that the Copper instructions generated by the OS for loading the View (and at least one ViewPort, of course) are executed.

So, you need to setup the View, the Viewport, the Bitmap(s), the colours palette, and then RastPort anyway. And the OS will generate the proper copper instructions that you can NOT avoid.

Which means: at least one rasterline is wasted only for that.

Beside that, you've A LOT of work to do for trying to achieving exactly the same thing which games did without the OS. And that's because, as I've said, you've to take care of the proper allocation & alignment of the graphic assets -> wasting a lot of memory (because memory is fragmented when the OS is running. And it's CONTINUOUSLY fragmented, unfortunately).
Quote:

or doing 'illegal' pokes.

Well, if you use a custom copper list then you're can easily do such illegal pokes, because you can bang the wrong register, set reserved bits, etc. etc..

Having the OS running protects you in some way (very limited on the Amiga, unfortunately), but once you take control of the hardware (even "just" using a custom/user copper list) you've opened the Pandora's box...
Quote:

Quote: 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. But USA Racing was never released, right? I don't think it's fair to reference a game which wasn't released as proof that some games couldn't be OS friendly.

Logically irrelevant: what matter is how a game works. The fact that it's unreleased says absolutely nothing regarding the dispute.

What matters on discussion are FACTS. They are AND should matter.

Since you've retired and have a lot of free time, 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).

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.

Of course, entirely using the OS.

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.

@bhabbott

Quote:

bhabbott wrote: @cdimauro Quote: cdimauro wrote: @NutsAboutAmiga I've absolutely nothing against such programs/tools. However, those were not available at the time, and probably not suitable for creating the very good games which we know very well. In short: it's too late. The market was already gone in the second half of the '90s. I agree with this. And since we are talking about stock A500's, anything that wasn't available before 1992 is irrelevant to this thread.

Irrelevant: games for OCS were released even after the A1200.

Reason: the market.
Quote:

The A1200 opened up a world of possibilities that made game programming much easier, including more memory, faster CPU, better graphics hardware, stock hard drive (in 'HD' machines), and a more efficient OS.

Yes. In fact, it was the second market of reference for the software houses.

But the first one was still the OCS one.
Quote:

But it was also too late to save the platform, as well as requiring a shift in attitude towards being more OS friendly.

Here I agree with Matt.

@pixie

Depends on the OS your talking about.

Can also be wrong about RTGMaster.
there has recreations of some libraries, and if this support everything,
or how they where tested I don’t know.

Last edited by NutsAboutAmiga on 23-Oct-2024 at 07:54 PM.

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

@NutsAboutAmiga

Cybergraphx was introduced in 1995, picasso96... In 96. I alhave no idea of PS4, but always was under the impression cybergraphx was the RTG standard

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@OlafS25

Quote:

there were several

Do you remember any names?

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

@pixie

As I understand it, different graphics API was developed by different companies, but they do share rtg.library as backend, should in kickstart normaly, so you never see it, and they do work in similar way.

EUAE / WinUAE’s native graphics API is picasso96.

http://wiki.icomp.de/wiki/P96_Driver_Development

Last edited by NutsAboutAmiga on 23-Oct-2024 at 08:33 PM.
Last edited by NutsAboutAmiga on 23-Oct-2024 at 08:30 PM.

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

@NutsAboutAmiga

I have searched in my distribution

f.e.

https://aminet.net/package/dev/misc/c2plib
https://aminet.net/package/util/libs/chunky_usr
https://aminet.net/package/util/libs/gfx3dlib_v32
https://aminet.net/package/dev/src/giraffe
https://aminet.net/package/util/libs/graphics3d
https://aminet.net/package/dev/misc/guigfxlib
https://aminet.net/package/gfx/misc/RainbowSystem
https://aminet.net/package/dev/misc/renderlib68k
https://aminet.net/package/driver/video/rtgmaster_user

all related to graphics and games

@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).

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?

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'.

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. A 'custom' copper list replaces the system copper list, and then you can do anything.

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). 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.