So, those code sample are not useable other than for inspiration to see how it's supposed to work.

Initially I hoped to at least use the OS macros, but they're dependent on stuff I don't have, so can't even compile those.

I worked around that by using the OS calling code from the Amiga HW Reference manual - no macros - just straight calling and that works.

So, I realized if I want to troubleshoot chunky gfx mode, I need some way of printing out values, unless I want to have a debugging set-up (possible, but not desireable currently).

Thus, I spent 2 hours learning the Amiga's bitplane mode, and same evening had functionality to print 8/16/32 bit return values in hexa.

Which is how I got the base OS calls working:
- graphics.library
- intuition.library
- dos.library
- cybergraphics.library

The one thing that didn't work was opening a 320x200 gfx mode.
So, in documentation, I found a method IsCyberModeID () and I stuffed all possible values to it (full 32 bit range) but it didn't find any valid Mode ID.

Which leads to me these assumptions:
1. Order of opening OS libraries is wrong
2. I have issues with the WinUAE RTG board config
3. CGX Drivers on the Dev Hardfile - I can open CGX, so I believe I have the CGX drivers installed, but maybe something needs to be enabled in the OS itself ?

I got a different code sample from flype on IRC, but his code also can't open a valid mode, so it looks like option 1 has been ruled out.

Leaving me with driver troubleshooting (option 2 and 3). I'll be hanging out on IRC for couple hours before I go to sleep and hopefully somebody volunteers in telling me where to click in the Workbench to figure it out.

I'll be definitely randomly clicking left and right like in those funny cats GIFs :)

Also, I found that cyberver command is supposed to tell me the version, but when I execute it from command line, OS can't find it - so it's probably buried somewhere in the filesystem and I gotta find it manually...

Especially the one with the caption : "I have no idea what I'm doing" :- ))))))))))

Randomly clicking on the Workbench produced an OpusDir app that appears to be file commander in the style of Norton Commander.

So, I can now browse the full filesystem of OS. Looking at libraries directory, I can see all kinds of .libraries but not the CGX lib.

So, even though I can successfully open the Cybergraphics.library via OS call, it doesn't appear to be fully installed.

I downloaded a German PDF on installing ZORRO card, and while my German isn't what it used to be, I should be able to at least make out installation directories :)

The oldest I am finding is 2009 : EXTERNAL LINK 

Look at here:

EXTERNAL LINK 

Kamelito

Now I could compile the necessary OS calls for opening the screen&window !

Thank you !!!

I still got bitten by the fact that I had the original bitplane Copper code at the start-up, but as soon as I properly removed all the bitplane code (that I originally used for debugging), I managed to successfully open the bloody window and can finally draw into the chunky buffer :)

Of the dozen+ HW platforms I coded for, displaying my first chunky pixel (I don't count the bitplane code I had running 3 days ago) on Amiga has somehow managed to take more effort (~10 days) than on the current top place occupied by Sega Saturn, which involved compiling its special version of gcc under completely silently internally-crashing msys32 (discovering that "feature" of msys was quite fun!) with special SH-2 compilers, which took 3 days each to configure to correctly compile under msys (in total 7-9 days).

Now I can start porting my codebase from Jaguar.  Finally :)

To be fair, the stuff would probably compile directly inside the emulator (or on actual Amiga). My main problem was:
- doing the cross compilation on Windows (finding latest Windows build of vasm took 2 days of random reading forums and accidentally stumbling upon one such thread at EAB, though later somebody posted a link here too)
- NOT using C, but insisting on Asm, as even the CGX dev code samples are in C - literally 98% of all code I found was in C

As I am going to introduce my own High-level language compiler into the mix (the Higgs), compiling straight on Windows is necessary.

What really shocked me, however, is the amount of C language and samples. WTF !

I really expected the ratio to be the other way around - e.g. 2% C and 98% ASM, given the ~7 MHz core speed of A500. Nope, that's not what it turned out to be :)

I definitely wouldn't call it "super OS-friendly", not yet for sure. Maybe I'll get there, if I can recover from OS launching another game and my game surviving losing the FrameBuffer pointer.

But, just to give you an idea what was going on, this is summary of OS calls to start the chunky mode:
Initialization:
Open graphics.library
Open CyberGraphX.library
Open Intuition.library
Open Dos.library
CyberGraphX._LVOCModeRequestTagList (requesterTags)
Intuition._LVOOpenScreenTagList (screenTags)
Intuition._LVOOpenWindowTagList (windowTags)

rendering:
CyberGraphX._LVOWritePixelArray (ptrFrameBuffer)

exiting:
Intuition._LVOCloseWindow ()
Intuition._LVOCloseScreen ()

Of course, just having NDK 3.9 was not enough - either missing files or after some rearranging it barfed 3 layers deep down in OS includes.

I should clean my code up and upload it somewhere so that in future this doesn't prevent people from trying to play with Amiga's code.

Pisklak, the standard way to get user input is by openening a borderless window on your screen and reading its message port. For a game lowlevel.library provides an alternative, though, where you don't need a window to get input. And, of course, there has always been the old direct-hardware approach, no need to bring that one up again. My point is that opening a window is one valid approach.

But, this is just first working prototype and a great learning experience.

Looking at the code from flype (his fire demo) and from a very quick look it seems he is also doing CALLCGX  LockBitMapTagList / UnLockBitMap and obtaining the pointer that way (not sure about other dependencies as yet), so that's what I shall try next.

There's also about 4 other OS calls for Audio, Keyboard, Timer, LowLevel library - which highly likely aren't related at all.

From my experience on Jaguar, the resulting code is atrocious at best. I spent a lot of time comparing ASM output after every compilation.
Now, it is possible, once you understand how each command gets translated, to write a "relatively" fast code, avoiding constructs that translate to 2 screens of instructions.

Perhaps gcc is better in this regard ? Never tried gcc on jag.

That being said, C is great for:
- apps / utilities
- adventures, turn-based strategies, board games, logical games, ISO-metric RPGs, top-down 2D RPGs, all screen-based games

Even 2D action platformers can be done well (assuming HW register usage and doing all sprite heavy lifting via Amiga's chips).

But, high-performance racing/shooter genre is not a good match.

Besides, I've already done the grunt work on Jaguar - so for me, it now scales really well - but I understand the idea of writing and debugging 100,000+ lines of ASM code is indeed daunting (in year 2020). You just gotta be the right kind of crazy : )))))

Grzegorz Wójcik (pisklak wrote:

But pls have in mind that I am myself begginer Amiga coder which not coding for too long so I might be wrong. In this case I am sure someone will correct this "help".

Please, you have no idea how I appreciate these technical discussions - not having to figure out the path through the OS minefield just by myself. Even if I don't respond to every single post, I truly appreciate everybody taking their time and sharing their experience.

The very best solution is having 3 Buffers.
1st is Displayed, 2nd is rendered, and 3rd is also rendered.
Using 3 Buffers you can unsync
the render loop from the display time.
This means if your render routine does not need to wait for the display.

For the final product I can highly recommend you to use Tripple Buffer and to only do PTR update.
 
On Vampire/SAGA the PTR SWAP is auto-synced with screen display.
This means all you need to do is 1 MOVE.L and the HW does the rest for you.