CyberGraphx ASM-Only SingleFile CodeSample to OpenScreen

[grond]

Originally Posted by VladR

Well, that sucks.

The Vampire can use the copper on chunky displays and it can display both a planar and a chunky screen at the same time. Better ask Gunnar for details.

But the copper doesn't do playfields, all it does is to update hardware register contents at specific screen positions. The way you worded your statement seems to indicate you haven't fully understood what the copper does, just mentioning.

Then the Gap between Jaguar and Apollo just got smaller. At 640x256x16bpp, that's a lot of CPU bandwidth (640*256*2*60 = ~19 MB/s) that just - poof - evaporated. And the CPU will be locked during all that time, leaving even less CPU time for the rendering...

The Vampire does 600 MB/s. I think losing 20 MB/s of it would be OK. Furthermore, the Vampire has a picture-in-picture feature which is very handy for running graphics-intensive stuff within a window.

[Thomas Richter]

Originally Posted by VladR

Yeah, I think I read in one of the samples that the FrameBuffer pointer returned by OS is only valid for the duration of frame ? Seriously ?

No, that is not what I have written. I wrote that the frame buffer pointers are valid as long as you locked them. They become invalid as soon as you unlock them.

Originally Posted by VladR

Why would OS reshuffle it every frame ? Surely nobody runs 3 games in parallel at the same time and expect them to run at 120 fps each?

Not "every frame", but, to give you just one example, in case the screens are reordered, and another screen is put frontmost. In such a case, the frame pointers may or may not change. Which implies that the user cannot switch screens while you locked the frame pointers. The reason for that is that most RTG cards have limited on-board memory (2MB, or 4MB), yet should and will be able to handle more screens than the on-board memory allows. In such a case, on-board memory is off-loaded to main memory if the corresponding screen is currently not visible.

Originally Posted by VladR

I really only need that stupid pointer for FrameBuffer from the OS (as, apparently, I can't just allocate it by myself otherwise it's allegedly OS-incompatible or something and I would have to kill OS, which I don't think I want users to have to reset the box after playing the game).

If you are into RTG graphics, you cannot kill the Os because the only way how to get it is from the Os. Lock the frame buffer, do your rendering, unlock the frame buffer.

Originally Posted by VladR

I am presuming here, that on a HW level, Copper would only take the FrameBuffer pointer that CyberGraphX gives me, so there would be no slow-down involved

RTG graphics does not have a copper. The copper does not work on RTG screens, it is only for native graphics. Just to clear up another misconception: "cgfx" is not a replacement for intuition. cgfx or its P96 counterpart, the rtg.library, are a replacement for the graphics.library. Intuition sits on top of graphics (or P96) for that matter. All graphics.library calls *also* work on rtg screens, though there are additional functions in the rtg.library that are not available in graphics. Such as getting direct access to a chunky frame buffer, i.e. for locking and unlocking it.

[Thomas Richter]

Originally Posted by VladR

So, just made a loop ($FFFFFFFF times) calling IsCyberModeID () and not a single ID found was good.

Wrong call, wrong level. For such stuff, do not use CGfx. The graphics.library display info database is good enough.

Originally Posted by VladR

I'll see if I can rustle up some CyberGraphX tool that would show, from the commandline, list of all valid modes.

Look into the asl.library screen mode requester. This will show all available screen modes, and let you select one.

[Thomas Richter]

Originally Posted by VladR

Well, that sucks. I presumed there's no way to disable the legacy HW present in every Amiga?

Errr, who handles the keyboard then?

Originally Posted by VladR

Wait, so now the 2D background will have to be copied every single frame ?

No, why. You copy it there, it stays there. However, the address of the frame may change. Remember, a user may switch screens at any time, and if that happens, P96 may or may not copy your graphics from the graphics card to main memory, or vice versa. That is, the graphics stays intact, they just get copied to a different address. If you want to update the rendering, lock the buffers so P96 cannot move them any more, do your rendering, unlock the buffer again. This way, your graphics is updated, and updated on screen if it is currently shown.

Originally Posted by VladR

We can't have Copper show one bitmap and CGX another ?

There is no copper on RTG screens.

Originally Posted by VladR

Guess I won't need to do ClearScreen then :- ))))))))

*Sigh* OpenScreen() will clear the bitmap or frame pointer you render on, though from that point on, its *contents* (though not its *address*) will not be changed, unless you change it explicitly, let it be directly (by locking buffers and modifying it yourself) or indirectly through some Os call (for example, by calling EraseRect() of the graphics.library). That is in no way different from native bitmaps, except that RTG bitmaps are generally chunky (there are planar modes, actually), and except that the *addresses* of the bitmaps may change, thus the need to lock bitmap pointers.

[VladR]

Originally Posted by grond

You keep forgetting that the Amiga is not a games console but a personal computer, more specifically a multitasking computer. This means that you may want to run many productivity programs at the same time. All of these will have some graphics output. Now PC graphics cards have some framebuffer and are a totally different concept to the original Amiga hardware that could just DMA from anywhere in the computer RAM (let's forget about chipmem vs. fastmem for a moment). This means that cybergraphx and P96 had to invent some additional layer of memory management. You may write directly into your screen (when it's in the graphic card's local memory) but must not assume that your screen will be in the graphic card's local memory when it is not being displayed (e.g. when iconified, not visible etc.) because then your screen data may have been shuffled out of the graphic card's memory again. You would then write into somebody else's screen that happens to be visible at that time.

Well, that begs the question - what's the percentage of 3D games on Amiga that can handle being run in parallel with other 3D games ? The ones that can be "put on hold" temporarily, you go and run another one from workbench, then go back and run, say, the third one ?


Because on PC, for a very long time, you couldn't really do that, and the moment you Alt-Tabbed, that was it for great majority of games. I have been implementing the memory pools under DirectX, so I recall what kind of mess that was - hunting down that last vertex or index buffer that had to be reloaded upon AltTab...

Originally Posted by grond

Now with the Vampire all memory is graphics memory and you are not tied to that limitation. You buffer will be in the same physical location regardless of whether it will be displayed or not.

I am extremely happy to hear that.
So, if I interpret that correctly, under emulator, and only until I get a real Vampire (then the testing will be easier), as long as I keep running just my game, OS shouldn't really have the need to kill my pointer. Cool !

[VladR]

Originally Posted by grond

The Vampire can use the copper on chunky displays and it can display both a planar and a chunky screen at the same time. Better ask Gunnar for details.

That'd be great. Since I have zero Amiga direct experience, all approaches sound good to me as I haven't implemented either one before.

Originally Posted by grond

But the copper doesn't do playfields, all it does is to update hardware register contents at specific screen positions. The way you worded your statement seems to indicate you haven't fully understood what the copper does, just mentioning.

Yeah, it goes without saying that I don't remotely understand anything Amiga-related
But, regardless of whether playfields can be used to avoid the 2*20 = 40 MB bandwidth hit, or if it's some other feature, as long as I don't have to pay that bandwidth price, I'm good.

Originally Posted by grond

The Vampire does 600 MB/s. I think losing 20 MB/s of it would be OK. Furthermore, the Vampire has a picture-in-picture feature which is very handy for running graphics-intensive stuff within a window.

It's not 20 MB/s, it's 2*20 = 40 MB/s, since if I have to copy the data, we must read it from one location (source bitmap) and write it to framebuffer (destination).


Personally, I'd rather spend it on some effect, or more sprites (say, for an OutRun), honestly.



But, as you say, there are things like PIP or the Vampire's ability to display both planar&chunky, so hopefully we can completely avoid any bandwidth hit on something as simple as a 2D background plane.

[VladR]

Originally Posted by Thomas Richter

Wrong call, wrong level. For such stuff, do not use CGfx. The graphics.library display info database is good enough.

Look into the asl.library screen mode requester. This will show all available screen modes, and let you select one.

asl screen requester is exactly the utterly useless overkill I want to avoid right now.


All I need is ONE chunky screen mode for my experimenting and porting the codebase from Jaguar.


Later down the road, yes I will implement choice of resolutions, but there's no way I'm deploying hundreds of builds to emulator every day and choosing the resolution. Every.Single.Time. That would be completely ridiculous

[VladR]

Originally Posted by Thomas Richter

No, that is not what I have written. I wrote that the frame buffer pointers are valid as long as you locked them. They become invalid as soon as you unlock them. Not "every frame", but, to give you just one example, in case the screens are reordered, and another screen is put frontmost. In such a case, the frame pointers may or may not change. Which implies that the user cannot switch screens while you locked the frame pointers.

Alright, that's fair enough. Then, as long as the game isn't being actively maliciously destroyed by the user launching two other games/apps in parallel, it's not a problem.


Is there any other common scenario when the OS would have to reshuffle the screens, even if my game is still in focus ?


I think I have a workable compromise here - all these OS features could be implemented in the Kickstarter tier style - if there will be more pre-orders, I can then go and spend 3-6 months babysitting the bloody OS and catching every brick it randomly throws into my code in the hopes it successfully destroys it

[DanScott]

Can this thread be moved out to the correct forum ???

[grond]

Originally Posted by VladR

Well, that begs the question - what's the percentage of 3D games on Amiga that can handle being run in parallel with other 3D games ? The ones that can be "put on hold" temporarily, you go and run another one from workbench, then go back and run, say, the third one ?

On AmigaOS you can run MacOS as a task in AmigaOS (it's called Shapeshifter) while AmigaOS is happily multitasking. Then in MacOS you can e.g. run DukeNukem3D and still switch to any other screen and program running on AmigaOS. You can keep your network connection up and everything. Unfortunately far too many AmigaOS games just shut down the OS for those few extra clock cycles that mattered when the standard configuration was a 7 MHz 68000.

[grond]

Originally Posted by DanScott

Can this thread be moved out to the correct forum ???

Why would this not be the right forum category?

[DanScott]

Coders. Asm / Hardware
Program the Classic Amiga chipsets and 68000 family CPUs directly, using Assembler

[amiwolf]

Originally Posted by DanScott

Coders. Asm / Hardware
Program the Classic Amiga chipsets and 68000 family CPUs directly, using Assembler

Labelling the new FPGA machines NextGen would be worth it just to annoy the PPC crew. Peace out RISC'y rascals!

I'm currently learning 68k assembler and for someone like me who struggles with simple decimal math, it's a steep learning curve but enjoyable nevertheless. Since Commodore never made an '060 Amiga, I'm not hung up over whichever third party accelerator uses an ASIC or FPGA to reach or surpass that performance. I'd hate to think 68k can't ever progress beyond Motorola's bygone chips.

[grond]

Originally Posted by DanScott

Coders. Asm / Hardware
Program the Classic Amiga chipsets and 68000 family CPUs directly, using Assembler

Ah, OK, you are only trolling.

[Thomas Richter]

Originally Posted by VladR

AIs there any other common scenario when the OS would have to reshuffle the screens, even if my game is still in focus ?

The input focus is not the relevant trigger here, but whether your screen is currently visible, i.e. topfront. For P96, the answer is relatively simple: If your screen is topmost, nothing will be reshuffled because that would certainly destroy the user experience. If the screen is in background (not visible), then reshuffling may happen whenever an application allocates RTG bitmap memory, and the rtg.library may have to make room in the graphics card RAM.


For CGfx, the answer may be a bit different. I do not know the system well enough, but I believe a second point where reshuffling may happen may be during screen dragging. I'm not clear how CGfx does this, but probably just by moving the display memory manually (i.e. a "drag" is a "big memory move"). Thus, if the user drags the screen, the memory is moved.



One way or another: If you don't lock the bitmap, your application dies. A couple of bad SDL (simple direct media library) ports for the amiga caused trouble this way: They open a screen, then lock the bitmap once to get the pointers, then unlock the bitmap again, and then let the user play with this pointer. This is incorrect as the pointer is, at this stage, already no longer valid. As soon as a user then moved the screen, or rearranged screens, the application dies away.

Originally Posted by VladR

I think I have a workable compromise here - all these OS features could be implemented in the Kickstarter tier style - if there will be more pre-orders, I can then go and spend 3-6 months babysitting the bloody OS and catching every brick it randomly throws into my code in the hopes it successfully destroys it

As said, it is not so simple. There is no way how to obtain an RTG screen except to call "OpenScreen()", and this is an Os call, so the Os must be running. The only way how to obtain the bitmap pointers is to lock the bitmap, and if I say "the bitmap", I mean "screen->RastPort.BitMap", *NOT* (!!!) "screen->BitMap". The latter is just a backwards-compatibility bogus bitmap that is worth nothing and should not be used.


From that point on, you *may* get away drawing directly on the chunky bitmap, well knowing that any activity the user may want to try on the screen may now freeze the system. For example, if the user now attempts t switch screens, the system freezes because your application still holds the bitmap locks, and the task that does the switching is the "input.device" task, executing some code of intuition, that executes some code of the rtg.library.

[DanScott]

Originally Posted by grond

Ah, OK, you are only trolling.

Not in the slightest. You need to learn the definition of Trolling.

This discussion has nothing to do with the original Amiga chipset. It belongs somewhere else.