Forum Replies Created
-
Posts
-
@Michael, I did contact him on Kickstarter.
The Kickstarter was updated and it looks like he gave credit to Hackvision/Team A.R.G., and the games mentioned were titled as they were initially (rather than their derived names) the last time I checked.
What will be telling is if the licences are left in tact in the code when they release their ports. Ultimately the code that I helped write is publicly available and can be used to either enjoy playing the game or create something new. All JOERI or I would ask is that 1) the licensce the code was published in is kept in tact if released so that it stays free and 2) we get at least a mention. I know though that those requests haven’t been honored in other cases. It is what it is though.
The Asteroids code was great and really pushed the limits of the TVOut code. JOERI and I similarly pushed the limits of the Gamby with a game called Dungeons. It will be interesting to see if both get ported to the Arduboy.
I found a decent explanation of structures here: http://jan.newmarch.name/OS/l5_2.html If you already know what they are and how to use them then great! Just wanted to make sure you had that.
Here are some code fragments to give you an idea of how to use a structure in your code:
At the top of your code (or in a .h file) you would want to have these sort of constants defined
#define MAX_BULLET_RECORDS 3
#define BULLET_HIDDEN 0
#define BULLET_FIRED 1
struct Bullet
{
unsigned char x; //x position
unsigned char y; //y position
unsigned char state; //bullet state
}
At the top of your program you would want to have something like the following:
...
char ship_x; //represent ship X position
char ship_y; //represent ship y position
char bullet_count;
Bullet bullets[MAX_BULLET_RECORDS];
....
I put in fake variables in the code example for the ship to give you an idea, however you would want to keep track of it however you are doing it in your own code.
In your main loop you would want to have something like:
....
//animate bullets, if they are active
handleBullets();
if (Controller.FirePressed())
{
fireBullet();
}
....
The code to these is the following:
void fireBullet()
{
if (bullet_count < MAX_BULLET_RECORDS)
{
bullets[bullet_count].x = ship_x;
bullets[bullet_count].y = ship_y - 10; //assuming the ship is 8 pixels high on the screen, with 2 px of extra space
bullets[bullet_count].state = BULLET_FIRED;
bullet_count++;
}
}
void handleBullets()
{
for (byte i=0; i
if (bullets.state > BULLET_HIDDEN)
{
//if we have moved off the top of the screen, then hide the bullets
if (bullets.y > 0)
{
bullets.y--;
} else {
bullets.state = BULLET_HIDDEN;
}
}
}
That should be a little more to go on. I know that examples do wonders for my understanding so hopefully this will help as well.
This is just one type of implementation (with a structure). You could do the same thing many different ways. I chose structures since it was easier for me to think of them. The important part however is understanding that you are setting up “state” in the independent bullet objects.
–trodoss
(Since neither txt nor ino for file upload is allowed I’m giving you the dropbox link)
I understand how that goes.
I use a Google Code site for my Arduino projects, and that at least makes the code available when forum sites will not allow certain attachments.
…So, hopefully the suggestions made will help. If you need anything cleared up just let me know and I will try to do so as best as possible.
Thanks,
–trodossI somehow can’t display the hearts under the ship (there are now in the top left corner).
It looks like you are tracking the position of the ship, so setting the x,y coordinates of the “hearts” would get them to display under your ship.
That being said, it will require lots of “redraw” processing to handle that sort of display though, as every time the position of the ship changed,
an enemy crosses their path, or another screen “event” happens you would want to re-draw these hearts.My ship isn’t moving while the bullet is displayed, only one bullet can be shot at a time, the bullet and the ship are flickering (really annoying).
You have a routine for the bullet that looks like the following:
void bullet(int currentX, int currentY){
int laserX = currentX;
int laserY = currentY;
while (laserY > -50) {
drawShip(currentX, currentY, true);
tv.set_pixel(laserX+5, laserY+5, 1);
tv.set_pixel(laserX+5, laserY+6, 1);
}
}
In that code, there is a loop that is going to loop through until the laser is finished with it’s animation before moving on. What you are after though
is “concurrency”, so that your bullet is “fired” and then the ship continues to move.In order to do that, you are going to want to do the following:
1) track the X, Y of each bullet outside the scope of the “bullet” loop
2) track the “state” of each bullet (not active, fired, hit, etc)You want to think of your bullets as independent objects that you can manage in a structure/collection. So… How familar are you with how structures work?
It seems like that would be the best way of handling how to mananage them. If you are then, great!In your main loop you would want to then handle each of your active bullets (aninmate, and check for collision). That way, they can all act independently,
and the main loop can manage all the game events.
And I've no idea how I could check if my bullet(s) collide with an enemy (with the code I have right now).
…Going back to structures, you are going to want to track “state” of your bullet.
If you are independently tracking the X,Y location of every “object” in your game, you can compare each of their locations (and size) to see if a collision
has occured. If everything is the same “size” it is a little easier. You can use a “bounding box” style of collision detection. If not, then Michael’s
implementation of collision detection is probably the way you would want to go.
void drawShip(int x, int y, boolean nein){
tv.fill(0);
...
It looks like you are blanking the screen each time you are doing things like drawing the ship or other actions.
Something you might want to consider is drawing a filled, black box over the ship image to “erase” it, so that it is not deleting the entire screen.
I use that trick a lot in the code I have, as it is a little more efficient (keeps from wiping the entire buffer between screen retracing).If you are looking for a simple example of how that would work, you can see the following:
http://code.google.com/p/trodoss-arduino/downloads/detail?name=moving_square.zip&can=2&q=I have a code example “Moving Square” that I originally wrote for the VGS that could be converted to the Hackvision fairly easily. The relevant part though is how it is handling the movement (it is just erasing what it needs to).
If you haven’t looked at Michael’s Asteroid code, you can find where he blogged about it here:
http://nootropicdesign.com/projectlab/2011/02/06/asteroids-on-hackvision/There are a few techniques in that code that you might want to consider. He uses a kind of collision detection that you will probably want as you are doing vector-based graphics.
Hopefully some of that helps. I am in a bit of a rush right now, however I will look back over your code a little later and see if there are specific things that I can give you pointers on.
Thanks,
–trodossHere are a few numbers that might help give you a little better idea of how much space is there (and what might be needed)
Elventure – 18,716 bytes (out of 32,256 bytes)
Poofy Adventure – 18,466 bytes (out of 32,256 bytes)
Either of those games are around 18-19Kb in size, so not terribly huge. There would be lots of “room” to expand them.
#include
#include
#include
#define TVwidth 128
#define TVheight 96
TVout TV;
void setup()
{
TV.begin(_NTSC, TVwidth, TVheight);
TV.select_font(font4x6);
TV.delay_frame(60);
}
void loop()
{
}
Just a “basic” sketch that uses TVOut and includes a font takes up about 5,096 bytes.
Without an included font, the same TVOout sketch takes up about 4,054 bytes.So, to use TVOut there is some overhead (about 4.5-5 Kb), however that is not terrible. The 10Kb size you have right now doesn’t seem to be really out of line for a TVOut-based sketch.
Provided that graphics are stored in code (and not in memory) you have a lot of “space” for graphics/logic. Depending on how you code your programs, you should also have room for logic. Compiled code from the AVR-GCC is relatively compact, so if you expect your game logic to be around 10Kb, then you should have enough space to work with.
Any “game data” that you plan on storing (like maps, text, etc.) you end up having to come up with a storage strategy that “fits” what you are doing. If you know you are going to use a lot of text, breaking it up into re-usable words/fragments is important. If it is just “SCORE” and “GAME OVER”, that likely isn’t necessary 😉 However, if you are making say a text-based adventure (a “Zork”-like game), you are going to want to “pack” text as tightly as possible (tokenizing, or LZW-like compression). There are similar strategies for vector-based graphics or bitmap-based graphics. It is all a matter of finding what “fits” for your particular project.
So, is 32Kb “enough” space? It is for some things, but certainly not everything. For arcade-style (classic 80’s) games it should work fairly well, and with a little planning you can make all sorts of games.
Hopefully that gives you a little more explanation.
–trodoss@moe wrote:
Unfortunately I think the game will take longer than you expect because I just have built the title screen and some little things, and I’ve not started developing the game yet… 😛
That’s ok. It is progress 😉
I might have a big problem because everything I do have now already takes up 10.000 Bytes of 30.000 Bytes available. I don’t have any feeling for storage on the Hackvision platform, do you think my entire game will have enough free storage?
It depends on what you are doing and how you store it.
One thing I would recommend is think about how you can break up your images into re-usable parts (tiles/blocks/etc.). It is easier to store them that way, and works well with the bitmap functions. I try to keep the tiles 8×8 in size, and only store what is needed.
[attachment=0:8yzyfo9k]elf_images.png[/attachment:8yzyfo9k]
(Elf images above, how 3 “blocks” can make up 2 “frames” of animationAre there a few things you can cut out? Sure. If you are not using fonts, then do not include them in your sketch. Technically, I think if they are not “referenced,” AVR-GCC will try to leave them out, however you can just opt not to compile that in and it will save you a little bit of storage.
If you really get in a pinch though, you can resort to compression. Since most of the data needed by TVOut is going to be simple bits, you can use “tricks” like RLE (Run-length encoding) to package a really big image into a much smaller space.
As far as other game data, if you could provide more details on that it might be easier to give a few suggestions.
–trodoss
Glad to be of help!
The easiest way to contact would be PM’ing on this site, or, if you could post your questions on the site and you might have a chance of a few more people to help answer your questions. I have created a few Hackvision games, however Michael is by far the expert on the platform, and I am sure he would have good input/advice to give as well.
Sounds like you may have a finished game to show soon, which is great!
–trodossHi again,
My bad. You were asking about vector graphics and all I mentioned was bitmap graphics…
I don’t know that there are any specific TVOut-oriented vector graphics programs, however I think Inkscape should be capable of what you would want to do:
http://inkscape.org/I am fairly sure you would be able to at least convert the output into the appropriate graphics primimitives used in TVOut.
Hopefully *that* will help.
–trodossHi,
I use the “bitmap” functionality a lot, since it is a little easier (for me) to think that way.
There is some information about the bitmap functions here:
http://code.google.com/p/arduino-tvout/wiki/BitmapsImage2Code is one of the applications you can use to create bitmap graphics. You can find it posted here:
https://forum.crystalfontz.com/showthread.php?5854-Image2Code-bitmap-to-source-code-converterI ended up having to code my own utilities to do the same sort of things. I attached an application that can convert bitmap images into the same sort of format. You may/may not find it useful, depending on what you want to accomplish. It is a simple command-line utility. If you look at the included .bat file you can see how to specify the input image size (default is 8×8).
Hopefully at least some of that helps.
–trodoss@SG57,
Hi there!As Michael said, the ATMega328 is has limited SRAM (2K) and processor speed (16 MHz).
I found that using PROGMEM for as much as possible is essential (see: http://www.arduino.cc/en/Reference/PROGMEM if you are not already familiar).
The TVOut library has some very nice features, however I have found that you have to extend at least a few to work well with bitmap graphics games. I am sure the same is true with vector-based games.
Due to how TVOut works, you have to use polling serial for debugging instead of the others that are normally used in the Arduino IDE (if you plan on debugging that way).
As far as adding a processor/co-processor I know that the Gameduino project already adds an FPGA as a graphics co-processor to an Arduino-based project, so it would work for a lot of ATMega chips.
http://excamera.com/sphinx/gameduino/There are also other projects that add other chips (like the Parallax Propeller MCU) as a “graphics co-processor” for an Arduino/AVR (DigiStorm (not yet released), or Chameleon: http://www.xgamestation.com/view_product.php?id=51).
Technically, it would even be possible to add another AVR as a graphics co-processor, or use an R2R ladder, or another chip like the AD725
See: Uzebox – http://belogic.com/uzebox/index.aspAny of those options can be “trumped” with a nice little color LCD with an SPI interface, and have the added benefit of portability. Something like this works well: http://adafruit.com/products/684 There are plenty of others available as well.
To me though, as interesting as these options may be, it comes down to a philosophical question: Do I want to get the most that I can out of a single chip (for the challenge), or do I want to add hardware/glue logic to make a simple chip do something “big” (ie: running Linux, http://dmitry.co/index.php?p=./04.Thoughts/07.%20Linux%20on%208bit). Either are fun, it is just a matter of what you want to do. I go down the path of using minimal hardware to make something interesting.
For a nice balance between minimal hardware/software and ease of programming on an AVR-based platform, Hackvision is a great product! Other alternatives will lead you down the path of more complexity (either in hardware or software) for really not a significant benefit. What do you need to have a good game platform? Video (in one form or another), sound, and a controller (or other user input). You have all of that on the Hackvision in one product.
[Edit:] Lol! That totally sounds like marketing copy, but seriously, I mean it 😉
Hopefully that helps.
–trodossHi again!
…So, I think I have the game in about as finished of a state as I can for now. I think I have the movement/jumping working a little better now, and added the music/sfx so it seems more complete.
If you find any heinous bugs and could let me know it would be appreciated. I could add more to it, however I have a few other projects I would like to finish up, and I am pretty happy with how this one has turned out.
@Michael, if you try it and you think it is in good enough working order feel free to post it.Thanks!
–trodossGreat! Glad they like it.
I will see what adjustment can be made on the horizontal jump.I am putting together the game and will post it when I have it completed.
Thanks!
–trodossI forgot to mention that I had to change some of the code for the Controllers library to get the code to compile in the 1.0 version of the Arduino IDE.
Michael may have already posted an updated version of the Hackvision code, however I didn’t have it, so I just modded what was there to get it to work.
–trodoss
