Is there any chance of a Space Invaders card? I think it would be almost as popular as a Tetris card.
Ha, hey Gaminginvader. The Tetris unit has a vertical screen, and a vertical screen probably would have never been put into production without Tetris. So you are right space Invaders would be an awesome addition to a unit with a vertical screen.
I don’t know if space invaders is still a title Midway owns, but I imagine any officially branded units for a game like space invaders is not something Kevin or the community would be too pumped about before commercial units are out : )
With that in mind, maybe open up a thread in the Development section about starting a project. There are no dev units with vertical screens that I am aware of, and the library for drawing to a vertical screen hasn’t been published yet, but you might find someone interested in pushing forward on an open source game that has the same mechanics as space invaders, or maybe there is an existing clone that can be forked and ported.
The only issue with rotating a Dev Kit or production Arduboy 90 degrees would be that the buttons may be in an awkward location, depending on the game and how the buttons were mapped. After all, the Tetris card will be capable of running Arduboy games on its second processor, in which case you’d have to rotate it for a horizontal screen.
As far as the library is concerned, the only thing the current library doesn’t support for a vertical screen is the built in text output. For everything else you just have to treat X as Y and Y as X, and deal with having a different corner as the 0, 0 origin. For the buttons, it’s easy to re-map them for a vertical orientation.
Oh yeah! I should have mentioned you can use MLXXXp’s rig to do a vertical screen no problem. And good tips MLXXXp, I honestly have no clue what changes were done to the library to do vertical rendering, so I could state how I’d approach it, but I’m not sure what the final library calls will looks like.
What I was trying to say was that, other than for text functions, for a vertical game you can just use the current existing Arduboy library with no changes.
You alter your thinking for your game design: X is Y and vice versa, and the grid has a different corner for the 0, 0 origin point. You would also have to logically rotate any data that you provided to the drawBitmap() and drawSlowXYBitmap() functions.
If it would make it easier to have the 0, 0 origin for a vertical screen at the top left corner, like it is now for horizontal, the display controller has the capability to flip the screen both vertically and horizontally in hardware. We would only have to add flipVertical() and flipHorizontal() functions to the library to send these simple commands to the controller, which is very trivial.
I agree there are a number of approaches. I just don’t want to make a claim about how to do it, and have the official libs be something totally different.
display.audio.<function> anyone? who would have seen that one coming : P
@ekem, I think we’re both on the same page with this. My point is that there’s no need to wait for vertical specific extensions, or a totally separate vertical library, to be released in order to develop a vertical oriented game.
You can just creatively use the existing library functions, as is. Although new library additions may make things simpler or easier in the future, your game will still work without using them, as long as the library remains backwards compatible, or available if replaced (it better, otherwise existing horizontal games with be broken as well).
Yep, just rotate your graphics before you render them… and remember the screen is truly horizontal. Changing everything to “think” vertical top to bottom probably isn’t worth doing at a low-level (it’s a lot of work). Doing it “easily” in some sort of software “vertical” addressing mode is probably going to easily be 2-4 slower than doing it natively.
Of course you could have drawVerticalPixel(x,y) or even a whole separate library for vertical mode, but honestly if you’re using the high level drawing functions your app is probably not going to be super fast in any case… the best way to use this hardware is to use super-fast sprite drawing code to draw images to the screen where you want them.
I mean obviously if you just redefine drawPixel to know about modes and ALL your drawing code runs thru drawPixel then you’ve just implemented “software” mode vertical with very little effort, but it is also going to be crazy slow.
This is real now 4 years later.