This exists!!

What is a Uzebox? How can I get one? Check here!
User avatar
L4rry
Posts: 242
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Re: This exists!!

Post by L4rry »

diegzumillo wrote: Wed May 02, 2018 12:57 am Now that I'm more familiar with the system I'm starting to find the limitations a little too constraining. In particular the visual aspect. I'll take a guess here that adding another microcontroller as a dedicated "GPU" of sorts is out of the question. Because right now this is visually very limiting, with no possibility of layers or manipulating pixels individually.
I would recommend you take a look at this game to appreciate what is possible with the limited resources available to the uzebox developer (mode 74):

https://nicksen782.net/a_demos/Emscript ... gameid=222

For me, personally, that is inspiring. The limited hardware resources and how you can use that to make an interesting game, is awesome :)

If we start adding co-processors, more RAM and additional hardware, why stop there? Just use Unity or UE4 then to target high end GPU 's . Maybe my counter example is too extreme, but, I would suggest targeting the standard uzebox hardware and video modes to see if you can come up with something interesting. It really is worth while :)
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: This exists!!

Post by nicksen782 »

There are many on that list to check out. They all can give an idea of what is already known to be possible.

Some games can have very customized video modes, Flight of a Dragon is a great example of that.

http://uzebox.org/wiki/Space_Invaders source code used lots of structs and structs within structs. Close to how a class would work. You can be as complex as you want or need to be.

An array of structs could hold each sprite x, y, direction, character type, etc. You could loop through and based on character type (or something else) do logic for that character. Player logic and enemy logic likely will differ so you can use the character type to filter out enemies when you are running player logic and vica versa.

Structs can contain pointers too. For example, a pointer to a map that you might draw with DrawMap2. Or perhaps an array of animation frames which are unique to each character type. Or perhaps each screen of your game (or world) has different music and tilemap data. You could load that information into a struct. Structs, like objects, can be used to keep related data together.

Uzebox is "retro-minimalist." That isn't perfectly defined but I see it as a console that has the ability to have retro-like games that are pixelated, size limited to a degree, and with limitations that require creativity in program design. It is a challenge. It is rather amazing what systems like the NES could actually do. Same with the Uzebox. The Uzebox does in software what the NES does in hardware and has some things that the NES doesn't have such as mass storage via SD card or external SPI RAM. There are pros and cons to this and it really helps to shape what an Uzebox game can become.

It can be harder, but the journey has its rewards and not just a completed game either.
diegzumillo
Posts: 31
Joined: Sat Apr 28, 2018 3:16 am

Re: This exists!!

Post by diegzumillo »

I played that one and it is inspiring! I hope I don't sound too 'whiny' here, as I do appreciate uzebox for the amazing thing it is and I'm sure a lot can be accomplished. My own personal expectations and preferences that I'm sharing here are totally subjective and arbitrary, really, and not criticism. But I'm sharing them anyway :D

I have a game idea that could be accomplished with very little. A prince of persia-like game. No camera movement needed, no need to separate things from background and foreground or gui, and very few sprites at a time.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: This exists!!

Post by D3thAdd3r »

diegzumillo wrote: Wed May 02, 2018 12:57 am From an artist perspective I would prefer lower resolution (128x128 or even as low as 64), less colors (8 colors would still be acceptable, or even less for a monochrome visual) but with more freedom of how to use the screen. Like a buffer (I think that's the term) where I can send stuff to it in whatever order I want and at the end of the cycle it sends it to the screen.
Uzebox is on par with retro hardware, and in a certain sense there is a bit more artistic freedom than something like NES since you can literally trade specifics back and forth to get a custom video mode towards what you need. Luckily many different angles on this are ready to use in the form of different video modes. The limitations can actually help too, as it keep the scale of games down to what is realistic to finish with 1 developer in their free time. Very easy to imagine a project, that in reality takes 10 times the amount of work it seems on the surface(regardless of what platform, there are just many specifics before a game is done).
diegzumillo wrote: Wed May 02, 2018 8:26 pm My own personal expectations and preferences that I'm sharing here are totally subjective and arbitrary, really, and not criticism. But I'm sharing them anyway :D
Share away, discussing this stuff can often times yield some creative way to accomplish things. Bouncing ideas off people, or even just saying it "out loud" can help envision how things can work.

On bitmap modes it really takes a brutal amount of cycles to draw out individual pixels to a buffer versus tiles. I am all for SPI Ram, and those 128x128 or 64x64 16 colors modes are doable. With that low of resolution, you can probably do some Prince of Persia thing fine. Load a full bitmap of the screen from the SD card to 3 places in SPI ram. Then draw sprites to the 1st buffer which will be displayed. Keep displaying that while you work on the 2nd buffer. When the 2nd buffer is done, display that. Then use the untouched 3rd buffer to write over all the pixels the sprites(at the old locations) wrote over in the 1st buffer(a technique called "dirty rectangles"). Now 1st buffer is your work buffer, 2nd is your display, and 3rd is still your master copy. Continue process and you are always displaying something without tearing, and have however much time is needed to draw the next frame. You may not be able to get 60hz, but depending on the game requirements and how short of screen, maybe you could? You get at least 640 bits of bandwidth per scanline, more if pre-buffering/working in HSYNC, so 128x128x4 just being 512, there is still more ideas left to be realized on the current Uzebox.
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: This exists!!

Post by Jubatian »

diegzumillo wrote: Wed May 02, 2018 8:26 pm I played that one and it is inspiring! I hope I don't sound too 'whiny' here, as I do appreciate uzebox for the amazing thing it is and I'm sure a lot can be accomplished. My own personal expectations and preferences that I'm sharing here are totally subjective and arbitrary, really, and not criticism. But I'm sharing them anyway :D

I have a game idea that could be accomplished with very little. A prince of persia-like game. No camera movement needed, no need to separate things from background and foreground or gui, and very few sprites at a time.
Thanks! :)

If you really want mostly Prince of Persia, that really doesn't take too much. For the simplest path, you could use Mode 3 (as everyone is using it), since Prince of Persia has at most two sprites on one screen (as far as I remember, assuming you realize collectible items such as potions by tiles), it should fit well within Mode 3's limitations even with larger sprites.

If you want to jump in something more complex, then Mode 74, the video mode which Flight of a Dragon uses (true that there are many things customized in that game, however Mode 74 is used as-is: the graphics techniques you see in the game are possible with the Mode 74 within the Uzebox repo). It is a little rough to start as the mode is quite complex. There is another game using this mode: Stormforce, which also has its source published.

Mode 3 is easier in that regard too that pixels are not that much wide, so using existing graphics designed for square pixels doesn't look too bad. Especially if you use the extended resolution option (256 pixels wide instead of 240). For Mode 74, you would have to pixel yourself, or possibly use graphics designed for Commodore 64's Multicolor mode (the pixel aspect ratio of Mode 74 is the same as an NTSC Commodore 64's in Multicolor).
L4rry wrote: Wed May 02, 2018 7:57 pmIf we start adding co-processors, more RAM and additional hardware, why stop there? Just use Unity or UE4 then to target high end GPU 's . Maybe my counter example is too extreme, but, I would suggest targeting the standard uzebox hardware and video modes to see if you can come up with something interesting. It really is worth while :)
I mostly started on my 2x1284 idea due to that the Uzebox is overclocked. I am being a little pushed around for doing this, I mean messing around with something disregarding the intended specs in this manner. So how to solve this? At 20MHz you normally can't do such graphics like at 28,6MHz. What is the biggest bottleneck there? Loading from ROM and swithcing between ROM & RAM tiles! So lets throw a 1284 at the problem which has 16K of RAM. But eww, the Uzebox is already CPU limited due to audio & blitting at 28,6MHz... And I found some wicked graphics modes which require utilizing the full 128K of ROM. Could I make it a GPU then to allow for sane C programming on another AVR for a full frame instead of just the VBlank? Sure! Then I was like wow, just how much raw 8 bit power this packs, still all DIPs! :D (In the current design, you could just solder together two 1284's side by side to get the core of this system, so it isn't even complex to wire it)

Anyway, sure the Uzebox is interesting on its own, especially the "let's see what can be done in 60Kbytes" aspect! :)
Post Reply