Gamebuino Library for Arduboy

Yes, I understand. I have only 1 question, how to increase the HEIGHT?

I am trying to adapt https://github.com/scmar/Digger

With few changes, it works really well. For example after increasing the buffer to 124 as WIDTH, the game is much wider with small changes as:

uint8_t _displayBuffer[(LCDWIDTH*LCDHEIGHT)/8];

void Display::update(void)
{
	frameCount++;

	for(uint8_t page=0; page<6; page++)
	{
		command();

		SPI.transfer(0x22);
		SPI.transfer(1 + page);
		SPI.transfer(7);

		SPI.transfer(0x21);
		SPI.transfer(((128 - LCDWIDTH) / 2) - 1); // based on WIDTH
		SPI.transfer(127);

		data();

		for(uint8_t col=0; col<=LCDWIDTH-1; col++)
		{
			SPI.transfer(_displayBuffer[(LCDWIDTH * page) + col]);
		}
	}
}

However, if I increase the HEIGHT, everything is messed (even the Gamebuino bootscreen that should be resized properly). I am sure that is something related with SPI commands but with a hint I could save the time required reading the full display controller documentation.

Basically I want to draw vertically more pixels than 48. I need a hint where that happens, or which command is related with that.

I know nothing about the Gamebuino library but shouldn’t this line>

for(uint8_t page=0; page<6; page++)

become

for(uint8_t page=0; page<8; page++)

to account for the difference between 48 pixels versus 64?

Also, what’s this line doing ((128 - 128) / 2) - 1) always equals -1. What did the original line do / say?

1 Like

I have pulled these lines from the Arduboy library …

#define COLUMN_ADDRESS_END (WIDTH - 1) & 127   // 128 pixels wide
#define PAGE_ADDRESS_END ((HEIGHT/8)-1) & 7    // 8 pages high

// set col address range
// 0x21, 0x00, COLUMN_ADDRESS_END,

// set page address range
// 0x22, 0x00, PAGE_ADDRESS_END

In which case, should your code be:

SPI.transfer(0x22);  // Set page address
SPI.transfer(0);
SPI.transfer(7);

SPI.transfer(0x21);  // Set column address
SPI.transfer(0); 
SPI.transfer(127);

Its also clear I know nothing about the SSD1306 as well :astonished:

2 Likes

Perfect, conversion is almost done, thanks a lot @filmote, I played with those values but it makes more sense after your post about the pages

1 Like

Ah good. As I said, I am just guessing how the SSD1306 works.

What settings did you end up with?

Several changes (basically making the screen size determine everything, the buffer, drawing, etc), I will post it in github or something later. The game is looking awesome, so much screen now compared to the Gamebuino.

But… I cannot draw a big rectangle now :confused: 128 as width fails, but 127 works well… there is a visible line at the end:
image

There is something wrong with the fillRectangle, or drawFastHLine or drawPixel when x is near the right side of the screen, maybe @akkera102 has a hint?

1 Like

Your challenge is very very interesting.

The max and min value of coordinate are
0-63 in the height. 0-127 in the width.

void Display::drawFastHLine(int8_t x, int8_t y, int8_t w)
{
	for(int8_t i=0; i<w; i++)
	{
		drawPixel(x+i,y);
	}
}

it use int8_t (“char” variable). this variable use only -128 - 127.
128 is not made to be usable.

1 Like

Basically use uint8_t or int16_t for drawing.
Frankly signed numbers make no sense for drawing absolute pixel coordinates unless you really want to accept coordinates outside the screen.

Technically speaking drawFastVLine could be made faster by filling in a whole column at once instead of filling in individual pixels (which would be a lot of unnecessary shifting and masking), though that might increase code size, I’m not sure.

Also it might be worth looking at how the Arduboy2 does drawHLine, it does it differently, which I assume means faster or smaller.

I’m guessing the original was ((ArduboyScreenWidth - GamebuinoScreenWidth) / 2) - 1, which is incorrect because of the -1, but that’s the equation for finding the X of the Gamebuino screen if centred. (I know this well because I have a helper function for calculating that that I wrote after realising how often I was trying to centre things.)

Arm yourself with knowledge:


Page 28 has some neat little tables describing some of the commands.
Page 34 onwards describe the commands individually in more detail.

Despite being the official datasheet some of the commands are very poorly described.

Oh! you are right :smile: that is the problem.

Using uint8 works for now as @Pharap commented too. The game looks amazing :slight_smile:


http://arduboy.ried.cl <- updated the hex here, with the arduboy improved version

If anyone wants to do something to compress the levels and fit them all, that would be amazing. Right now I had to remove about 25 levels to make it fit

3 Likes

Is the level format documented anywhere or would I have to read the source to understand it?

You have other projects to do *(you know which one I am referring to) … I am going to stalk you to complete them.

Clearly I was asking for other people’s benefit :P.

1 Like

Nice work converting these apps. :+1:

1 Like

The second alternative

2 Likes

@eried
good job!

Just as you said. -1 will del from my library.

2 Likes

i am using a homemade arduboy and its not working

If you’re using a different screen or pin arrangement then it possibly won’t. It’s using low level commands that likely only work with certain screen and pin arrangements. E.g. it probably won’t work for SSD1309 screens.

I’m using ssd1306 1²C

The I2C connection is the problem. This library is using SPI.

Hi @eried ~
Thanks for this fun conversion!
Unfortunately the EEPROM used overwrites some of the first 16 bytes, which is system reserved. In fact… the code does something quite nasty… it will wipe all 1024 bytes of EEPROM, every time the game loads :grimacing:

There’s a lot of info available on EEPROM usage (and collisions!) here. You might also want to look at the latest developments in extending support for the ‘Arduboy2’ library. Please shout out if you need any help fixing the code.