RPG game + LED pixel game system hardware

[Saimaster13]

I already made my own custom controllers using 4051 ICs, but interfacing those Nintendo controllers would be pretty nice so I might come back and do that later. That is an awesome idea, especially since it took me hours upon hours to make and debug that one controller. It took me around twice the amount of time to wire the 8 controller connectors.

I think progressing from green to yellow to red backgrounds wold be rather hard to play since your character will always be green and enemies yellow. If the background is always red, it will be easy to see your character and notice enemies and harder for you to get lost and enemies to sneek up on you.

We seem to think a lot alike sometimes, I already had the key type thing in mind and characters displaying text on LCDs was the main reason I programmed the LCDs in the game.

I do not think I am very good at riddle making, so the focus will probably be on killing stuff for npcs, but I will do my best to incorporate a riddle or two. If you or anyone else has any ideas for side quests, riddles, or anything similar, I'd love to hear them, I already got two people thinking stuff like that up already.

Also, if anyone wants to be in the game (Brad the tavern owner, Stacy the potion shop owner, Joshua the town idiot, etc.) I'd love to have your requests and put you in (if and when I get that far into making this game.) You could even request what color you want to be. But no matter what color you request, you will be green. Always green.

Lastly I want to decide to either make the setting of the game in old times (like all the games with knights, swords, archers, and magic) or in post-apocalypse times (swords, few and expensive guns, bows more common, devastation to the land, settlements here and there, probably some type of magic too.) I could also use suggestions on that too.

[Saimaster13]

Also, I'm planning on making the game screen kind of like this when I make a bigger screen.
The red is the main screen, it will either center on player 1 or the majority of the players.
The other lightly colored squares follow each player. If a person gets lost, or wants to solo, then they can use that screen to find their way back or do what they want to do. Also, if the players go into a cave or something, then the main screen might not follow them, but will stay on the "world map."

[Saimaster13]

How did you code the scrolling of your pixel man game Brad? I set everything to display in respect to the player, but how did you make so it did NOT scroll when a player was close to the wall?

[Saimaster13]

So I wanted to eventually make the game 64x64 pixels, however, when I the code shiftOut 32x32 pixels you can see the screen flash a little bit, but when it shifts out 64x64 bits, its pretty annoying. Is there a way to make so the screen doesn't flash as much? Is that what the 74373s can be used for?

[Saimaster13]

Okay, so I did some more testing and it doesn't look too promising. I tested splitting up each of the 64 boards of the 8x8 matrices matrix and running them separately
(such as something like this:

Code: Select all

void matrix1Driver()  
  shiftOut1();
};       
void matrix2Driver(){
  shiftOut2();
}
etc.

)

and splitting them up but running them together
(such as:

Code: Select all

void shiftOut allMatrixes(){
  shiftout1();
  shiftout2();
  etc.
};

)

and I am getting the same results with each.
If I run 3 sets of shift registers (one set being three shift registers, one anode and two cathodes, one for red, one for green) the screen is fine, as I get up to 4 sets, you can notice a little bit of flickering. Five sets is what sets it over; the flickering is very apparent.

The problem:
To make so the screen does not flicker too apparently on a 64x64 display, the only thing I can come up with is adding 4 more Arduinos to run 4 32x32 matrices and having the first Arduino tell the others what the anode and cathode data are. I may have to add a 6th Arduino to coordinate the main program and what the matrices need to display.
So the supplies will be:
5-6 arduinos which is ~ $20-$30 (I will not need the main Arduino board, just a bootloaded chip which I will bootload myself
48 shift registers to control the 4 32x32 matrices or 64x64 matrix
extra shift registers and some decoders to communicate important information between main program Arduino and other Arduinos
more ICs and Arduinos if I want a flicker free display

Does anyone know a better way to go about this? Is there a microcontroller that can drive shift registers faster so that I hook up a master Arduino to that so that the other microcontroller can control the matrices?

note: The problem is NOT just that the duty cycle is too small, the Arduino also can't write data to the shift registers fast enough. If it could, then it could drive a bunch of small matrices adding up to 64x64 with one chain of shift registers and have a duty cycle of ~ 1/8.

[brad]

This is probably the funniest line i've read on this forum!

Also, if anyone wants to be in the game (Brad the tavern owner, Stacy the potion shop owner, Joshua the town idiot, etc.) I'd love to have your requests and put you in (if and when I get that far into making this game.) You could even request what color you want to be. But no matter what color you request, you will be green. Always green.

That would be great to play a role in the game - maybe I could be the underground secret electronics supplier - you need to find me to get some special part to fix your - something... (maybe a weapon?)

I have to head off to work now but will get back to you about how I made the screen scroll properly - basically you just have some if statements to check if the player is close to the extreme edge of the screen or not. you then run one piece of code to scroll the screen if they are not near the edge - and a different piece of code to keep the screen still and have the player move if they are near the edge.

As for you flickering issue - the microcontroller isn't fast enough to deal with sending out and updating that much data. I will show you how my screens work though.

I'll get back to you!

[Saimaster13]

Ahh, the scrolling makes sense then, I understand how you did it.

[Saimaster13]

To add on more questions:

The longest datatype on the Arduino is unsigned long. It has 32 bits, and I write my map in bits. So this effectively limits the map size to 32 pixels wide (but infinitely tall) but I want at least 64 bits wide, if not more. The only other options I see is to make a string for each bit, but this uses a great deal more space, in my map it was ~70x more space. The other option would to have 2 long datatypes, one being the first half of the map, the other second. This not the best thing to have or the easiest to code or make new maps, but that currently seems like the only real option. Is there something better to do than this? It'd be pretty awesome if there was an 8 byte or 64 bit, or even a larger datatype that I could use.

[Saimaster13]

Never mind about that last post, I just made so that 2 32bit numbers made up the whole map.

Got a test map going and working on a 7x7 display! (I uncoded 1 row and 1 column so the player is always in the center)


It is pretty much just a blank map... but

Code: Select all

  0b11111111111111111111111111111111, 0b11111111111111111111111111111111,   //1
  0b10000000000000000000000000100000, 0b00000000000000000000000000000101, 
  0b10000000000000000000000000100000, 0b00000000000000000000000000000001,
  0b10000000000000000000000000000000, 0b00000000000000000000000000000101,
  0b10000000000000000000000000100000, 0b00000000000000000000000000000001,   //5
  0b10000000000000000000000000100000, 0b00000000000000000000000000000101, 
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001, 
  0b10000000000000000000000000100000, 0b00000000000000000000000000000101, 
  0b10000000000000000000000000100000, 0b00000000000000000000000000000001, 
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001,  //10
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001, 
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001,
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001,
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001,
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001,   //15
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001, 
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001, 
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001,
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001,
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001,   //20
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001, 
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001,
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001,
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001, 
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001,   //25
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001, 
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001, 
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001, 
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001,
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001,   //30
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001, 
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001,    //32
  
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001,    //1
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001, 
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001,
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001,
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001,   //5
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001, 
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001, 
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001, 
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001, 
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001,  //10
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001, 
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001,
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001,
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001,
  0b10000000000000000000000000000000, 0b00000000000000000000000000000001,   //15
  0b11111111111111111111111111111111, 0b11111111111111111111111111111111, 

[Saimaster13]

Well, ran out of SRAM. I tried using PROGMEM but had problems, its getting late so I'll try again tomorrow. If anyone knows how to use the PROGMEM function on the Arduino, it'd be a great help if you could teach me how to store maps in it.

[brad]

Great work with getting the 64 pixel width working!

As for running out of RAM - I didn't even pick up on the fact that you were using ram!

What you want is to use constants (instead of variables) constants will reside in program memory - they just can't be changed. If you want the screen data to be able to save changes. for example in my super pixel bros game, when you hit a block - it disappears. Even if you leave the screen and come back, that block should still be gone. To do this, you just load each new level that you are currently playing into SRAM and you can update the level data.

Having said that - you want to use constant arrays like this:

Code: Select all

const byte map[8] = {B11111111, B10000001, B10111001, B10111001, B10111001, B10000001, B10000011, B11111111};

How much program memory space is used up so far?

[brad]

As for updating the screen - basically you need hardware to help you. The 32x16 LED displays that I have been playing with have a 1/4 scan. This means that it actually draws four lines of 32 pixels at a time. This means that to draw an entire 16 lines of 32 pixels - it just has to scroll through four times. This allows the screen to update faster to reduce flickering.

[Saimaster13]

How much program memory space is used up so far?

About 11k out of 32k max bytes are used up so far In my program. I got the map changing down, and also added the use of a shield. I tried putting a const in front of the map strings, but it still seems to take up SRAM...

[brad]

This should work for you.

Make sure you include this header file:

Code: Select all

#include <avr/pgmspace.h>

Then when setting up an array, simply put PROGMEM before it:

Code: Select all

PROGMEM byte map[8] = {B11111111, B10000001, B10111001, B10111001, B10111001, B10000001, B10000011, B11111111};

Let me know how you go.

[Saimaster13]

I'm looking into that, but the problem is that you have to recall it in your code to actually get the data back from the flash memory. I'm doing my best to find out what code I need to use. Also, I am using unsigned long, not bytes (bytes would probably be easier, a lot more examples of that in PROGMEM.)
Anyway, for the storing I have:

Code: Select all

#include <avr/pgmspace.h>
const prog_uint32_t MAPGreen[2][97] PROGMEM = {
{lots and lots of numbers),
(that is a lot of data..},
};

I still need to recall it...