I started a new tread :)

[stama182]

Hello again! Thanks for all help so far.
Now winuae starts when i press F5, but I see no traces of my program in it. All commands I type to AMIGaDos fail, and I see no trace of the game.log that Im supposed to write to. :)

So If you have even more patience, Ill be glad for some more help...

Have a nice weekend regardless!

GoodOldWorld.zip

[tehKaiN]

Ok, so I've added the .vscode/launch.json file like explained in the docs, looks like this:

{
	"version": "0.2.0",
	"configurations": [
		{
			"type": "amiga",
			"request": "launch",
			"name": "Amiga 500",
			"config": "A500",
			"program": "${workspaceFolder}/build/alloldworld",
			"kickstart": "D:/usr/Documents/Amiga files/WinUAE/kick13.rom",
			"internalConsoleOptions": "openOnSessionStart"
		},
		{
			"type": "amiga",
			"request": "launch",
			"name": "Amiga 1200",
			"config": "A1200",
			"program": "${workspaceFolder}/build/alloldworld",
			"kickstart": "D:/usr/Documents/Amiga files/WinUAE/kick31.rom",
			"internalConsoleOptions": "openOnSessionStart"
		}
	]
}

and I get no error, executable works! Indeed, log file isn't created, but I created a breakpoint on logWrite in genericCreate() and execution stopped properly, so there's that. Since path leads to alloldworld, it needs both alloldworld.exe and alloldworld.elf in that folder. That's how vscode extension works and I can't really do anything about that - sorry!

Now, about logging - you need to put ACE into debug mode. Depending how you call cmake, you can do it as follows:

• if you call it from command line (e.g. cd build; cmake ..), you can add -DACE_DEBUG=ON to the command line and it'll use that
• if you just let vscode do its trick, you can go to cmake ui, find ACE_DEBUG variable, toggle it on and hit SAVE button

• or, if you can't be bothered with that, add set(ACE_DEBUG ON) in your cmakelists.txt file somewhere before the add_subdirectory(deps/ace ace) command.

This will enable debug mode, and now you have 2 extra choices:

• if you want to have file logging which is horribly slow, but works even outside emulators, use the GENERIC_MAIN_LOG_PATH define as you have it in main.c
• if you want to have fast logging directly to vscode debug console, also set the ACE_DEBUG_UAE cmake var.

Hope this helps!

[stama182]

I finally build the tools!

I hade to make two things to make it work.
First add theee two lines in CMAKELists in tools folder:
set(CMAKE_C_COMPILER "D:\mingw64\bin\gcc.exe")
set(CMAKE_CXX_COMPILER "D:\mingw64\bin\g++.exe")

Then for some strange reason I got a builderror in build.cmake because he coudnt find windres, despite me having windres in
powershell as 'set-alias -name windres -value D:\mingw64\bin\windres.exe'

So I replaced it with the complete path in build.cmake, and then it worked!
Thank you :)

[tehKaiN]

Nice! You can also inject those vars using cmake .. -G "MinGW Makefiles" -DCMAKE_C_COMPILER=path/to/gcc -DCMAKE_CXX_COMPILER=path/to/g++. Perhaps cmake doesn't like set-alias thingy. I think it'd be also fixed with adding D:\mingw64\bin into PATH envvar.

[stama182]

Hi again, and hope you had a fine week.

I have now managed to load an image as a background!

Quick question:
I think the following code should manage to move the background somehow, but it doesnt. It manage to show the background,
but it doesnt move. But it shows. So Im a little happy for that still :)

void gameGsLoop(void) {
// This will loop forever until you "pop" or change gamestate
// or close the game

if(keyCheck(KEY_ESCAPE)) {
gameExit();
}
else {

scrollPosX = scrollPosX + 1;
for(UWORD uwX = 0; uwX < s_pMainBuffer->uBfrBounds.uwX-64; uwX += 16) {
  for(UWORD uwY = 0; uwY < s_pMainBuffer->uBfrBounds.uwY-64; uwY += 16) {
    blitCopyAligned(pBmBackground, scrollPosX, 0, s_pMainBuffer->pBack, uwX, uwY, 16, 16);
  }
}

// We'll come back here later
}
}

[tehKaiN]

blitCopyAligned() is an optimized variant of blitCopy() where the assumption is that x coords are always multiple of 16 - it doesn't do per-pixel shifting during copy. You could try using blitCopy() (with MINTERM_COOKIE as last param) instead.

However, there's an easier method for doing scrolled background. Just set up simpleBuffer with bounds bigger than the viewport (e.g. TAG_SIMPLEBUFFER_BOUND_WIDTH, 640, TAG_SIMPLEBUFFER_BOUND_HEIGHT, 512) and then use camera functions to move it, e.g. cameraMoveBy(s_pMainBuffer->pCamera, bDeltaX, bDeltaY) or cameraCenterAt(). This should work flawlessly assuming you have following functions at the end of your game loop:

viewProcessManagers(s_pView);
copProcessBlocks();

For bigger scrolls, you either need to render each frame from scratch, as you're trying to do, which will result with degraded performance (25fps tops, I think) or use tileBuffer instead of simpleBuffer, which does some wacky hardware tricks to achieve semi-infinite scroll (65k x 65k pixels).

[stama182]

Thanks again! Havent tried it yet, but this gave me hope :)

[stama182]

Yes it did work! Of course :)
But this makes me think Im missing some documentation? There isnt much I think on the page. Or were is the main documentation about all objects in ace?
This is basicly what Ive got:
https://github.com/AmigaPorts/ACE/tree/master/docs/tools

And If you dont have anything else to do, feel free to look at my current problem :)
game.txt

This code scrolls. But I would like to not scroll the lower part of the screen.
I have defined two viewports. I made viewport1 192 high becuase I didnt want it to take up entire screen. Than I made the mainbuffer for that viewport1 bigger so that I had something to scroll. And it kinda works, but this makes viewport 1 kind of override the other viewport. I wanted somthing like lemmings, were the lower part doesnt move, as its a menu with all skills. I want viewport one to move with the scroll, and viewport 2 to always display the same image. Sort of.

[tehKaiN]

yup, the docs are a bit incomplete - still a work in progress thingy.

You almost got it right - you still need to create simplebuffer for s_pVpSkills because a viewport by itself doesn't have any backing bitmap - you need buffer manager for it - be it simplebuffer, scrollbuffer (for more memory-efficient scroll stuff but requiring knowledge what exactly are you doing) or the tilebuffer. If you omit it and just create plain viewport without anything else, it will most likely result with some crazy stuff on screen and/or prior viewport bleeding into the other one.