FPS development


(Jean Charles Lebeau) #82

Yes, you are too good to keep it only on the classic Gamebuino, for all of us, you should port it on Arduboy, META and maybe Pokitto and Pico-8 :slight_smile: The price of the talent, sorry :smiley: It’s a joke and a hope too…


(cyril guichard) #83

I would be up to do the graphics: I already started this > [WIP] Maze of Doom - 1 bit FPS and would love to finish it.

My walls do not have textures because we couldn’t make it work, but I can of course provide texture tiles if needed


#84

I’m a sucker for your artwork, maybe best of both can be combined. I’ve got some extra time off in a couple of weeks and have a look at the projects. Is Maze of Doom available somewhere?


(cyril guichard) #85

I don’t think the coder I was working with open-sourced it, but I can put together a zip for you with the graphics pretty easily over the week end, if you want? (and then we can discuss what’s missing, like wall textures, if we are going to keep those)


#86

Sounds good. Seeing Wolfduino it needz textures :stuck_out_tongue:


(cyril guichard) #87

It will get textures then :slight_smile: - One thing where I will need direction with is the export size of the sprites: in the previous attempt, we had trouble resizing the sprites down (as in, depending on how close/far they are with the perspective) without seriously mangling the graphics.

As a result, I did all sprites at 1616 but exported them as 3232 (so double, so that they could take a reasonable downsizing without loosing their readability). Looking at the Gamebuino gif, it doesn’t seem to be the same case, but do you know how this is going to work? I’ll need to know this beforehand for the enemies and walls textures.

Here is an example of a current enemy sprite super-sampled:

soldier + soldierMask = soldierSprite


#88

upscaling to 32x32 sounds a waste. I saw wolfduino used 16x16 so I’d say stick with that. I’m not sure how it all works/should work. That’s something I need to look into.


(Pharap) #89

You mean @igvina?

If the source is available then someone else will be able to pick up the baton and carry on.
If it isn’t then all that time spent on the programming was effectively wasted.


(cyril guichard) #90

not sure how to answer to this… it may be better to @igvina to step in and say what he intended for the source moving ahead… I know that , as far as I like to do business, my contribution is locked into a final product, so since there is none, I’m perfectly fine moving on to the next person that wants that type of game happen… We had no particular contract setup when we started working, I’m just trying to be straight-forward and honest :slight_smile:


(Michael Gollnick) #91

Was hunting a bug now for some weeks. The game started to behave strange, e.g. walls started to move or disappear, enemies disappeared, graphic glitches and the like… like glitches in the matrix :star_struck: … waited for the white rabbit but nothing happened :stuck_out_tongue_winking_eye:

While searching for it I found several other bugs and could fix them :sweat_smile: but the real bug really kept me busy.
At the end I found that it is a stack overrun so I worked on the code like crazy to reduce stack usage but failed all the time. I could not figure out where it happened. My functions (worst case scenario) did not use that much stack and that really puzzled me. Then finally I found this webpage:

http://jheyman.github.io/blog/pages/ArduinoTipsAndTricks/
http://jheyman.github.io/blog/pages/ArduinoTipsAndTricks/#checking-stack-usage-at-runtime

The solution for my problem was to not inline one big function. It was inlined automatically but cause serious issues on the stack. I added the attribute ((noinline)) to it and suddenly the issue was solved. I could even use more bss memory from then one without any issue with the stack.
If I have some spare moments I need to dissect the disassembly of both versions to see what happened.

Posting this just in case one has similar issues.


(Miloslav Číž) #92

These are painful but you can’t avoid getting in these situations from time to time, I’ve been there not long ago. It’s rewarding to finally catch that bug. These tips are definitely useful – the links would be very suitable to be included in some tutorial here (possibly the Arduboy tutorial for programmers who already know C++ – anyone up for it?). Anyway, thank you for sharing this :slight_smile:


#93

Thanks for sharing that info.

Probably what happens is that when code is put inline the total number of local variables in the combined function will increase. But since there is a limited set or registers available to handle them, the stack will be used to store them.

A trick I use to locate code in a disassembly fast is include the following line in the source

asm volatile("dbg:");

Then in the disassembly you can search for <dbg> (You can use any label you want though)


(Michael Gollnick) #94

Thank you for the explanation! That makes sense now.
Also thanks for the debugging trick. Actually I have even a similar technique. I have a macro that inserts 3 nops.
I use it to surround code to see how my algorithms are translated so I can see how I can improve the code.


(Pharap) #95

There was a similar issue with Sprites::drawPlusMask a while back where preventing inlining fixed it.
The cause was slightly different, but the result was the same.


(Michael Gollnick) #96

I have polished the engine a little bit and added some more features (e.g. triggers, game menu). Sorry for being so slow. The little time I have I spend on freeing PROGMEM and fixing some bugs. Still there a a few glitches left but I think it is good enough to release it soon. I am doing the level right now and after that I need to finish/make nice graphics.

The code will be released as well of course.

Is there a need to provide an .arduboy file? If so, how can I create such a file? Any hint is appreciated.


(Kevin) #97

This is one of those concepts along with RPG games that push the code optimization to the max, both for processing power and also now obviously memory constraints. But what if there was some more flash memory added? With something like external flash memory available, how much would that help the situation?

How much of the size of the game are resources that could be offloaded to external memory?


(Michael Gollnick) #98

Yes. Much of the PROGMEM is used by level data, textures and some translation tables for acceleration. With more memory I could add much more textures and bigger/more levels. RAM limits the number of dynamic resources like enemies, items, doors, moving wall and triggers. From performance points of view there is not so much of an issue right now. Of course it requires some optimization and limit of features but that is ok for this type of game for the Arduboy.

A wild guess would be that I could easily offload like 10k of data to external memory. But keep in mind that the external memory access should be fast. Currently it takes about 3cycles to get a byte from PROGMEM.


(Pharap) #99

It’s just a renamed .zip file with a .json file inside, and a few optional images.

Here’s what Minesweeper.arduboy looks like when I open it with 7zip:
MinesweeperArduboyFile

And the info.json looks like this:

{
	"schemaVersion": 2,
	"title": "Minesweeper",
	"description": "A simple Minesweeper game, available in multiple languages.",
	"author": "Pharap",
	"version": "2.0.0",
	"date": "2018-08-21",
	"genre": "Puzzle",
	"publisher": "Pharap",
	"idea": "Pharap",
	"code": "Pharap",
	"art": "Pharap & vampirics",
	"url": "https://community.arduboy.com/t/minesweeper-multiple-languages-available/5642",
	"sourceUrl": "https://github.com/Pharap/Minesweeper",
	"email": "",
	"companion": "",
	"banner": "Banner.png",
	"buttons":
	[
		{
			"control": "Up",
			"action": "Navigation"
		},
		{
			"control": "Right",
			"action": "Navigation"
		},
		{
			"control": "Left",
			"action": "Navigation"
		},
		{
			"control": "Down",
			"action": "Navigation"
		},
		{
			"control": "A",
			"action": "Reveal tile"
		},
		{
			"control": "B",
			"action": "Mark tile"
		}
	],		 
	"screenshots":
	[
		{
			"title": "Main Menu",
			"filename": "Menu.png"
		},
		{
			"title": "Gameplay",
			"filename": "Gameplay.png"
		},
		{
			"title": "Losing",
			"filename": "Losing.png"
		},
		{
			"title": "Themes",
			"filename": "Themes.png"
		}
	],
	"binaries":
	[
		{
			"title": "Arduboy Version - English",
			"filename": "Minesweeper.EN-GB.hex",
			"device": "Arduboy"
		},
		{
			"title": "Arduboy Version - French",
			"filename": "Minesweeper.FR-FR.hex",
			"device": "Arduboy"
		},
		{
			"title": "Arduboy Version - German",
			"filename": "Minesweeper.DE-DE.hex",
			"device": "Arduboy"
		},
		{
			"title": "Arduboy Version - Spanish",
			"filename": "Minesweeper.ES-CL.hex",
			"device": "Arduboy"
		},
		{
			"title": "Arduboy Version - Aussie",
			"filename": "Minesweeper.EN-AU.hex",
			"device": "Arduboy"
		},
		{
			"title": "Arduboy Version - Cockney",
			"filename": "Minesweeper.EN-LCY.hex",
			"device": "Arduboy"
		},
		{
			"title": "Devkit Version - English",
			"filename": "Minesweeper-Devkit.EN-GB.hex",
			"device": "Devkit"
		}
	]
}

Unofficial Team-ARG game repository for Arduboy Mate
(Michael Gollnick) #100

Many thanks. That will help.


(Scott) #101