Oh! Speaking of (and this may totally influence your decision hehe)…have you seen this yet? Just came across my news feed yesterday.
You won’t get nearly that performance on a zero, of course, but wow! I bet it would still perform well for your console project. It’s not the same as the open-source Vulkan project; it’s specifically for Pi devices and written by an Nvidia engineer as a personal project…spent 2 years on it!
With MMOs, the server often renders the complete processes, and the computer renders the local main object and remaining local available processes. It only processes what it needs locally.
We’re only talking about two devices… plus, a lot less space is used. Minecraft is much bigger.
If the blocks are smaller, they could fit more than the mobile version.
I wonder if we could run a server for it though. It might have to run over LAN.
You think so? I mean, the Ringo’s small resolution means we don’t have to devote much to graphics, especially static objects. In fact, one would argue that, on a platform such as this, using a vector graphics engine might be ideal in both size and performance.
That is a very strange concept. I only had a small amount of training in visual arts. I don’t remember much about things like Vector vs Raster…no hands on training with anything we do.
I can say though…by the maths, we can deduce all logical variables associated by screen size. It may be possible to cut corners and build simple short cuts. However, we must bear in mind our screen size. If for example, the screen we’re working with is a flat 400 screen size. That is close to our dimensions. We can easily divide 400 with binary fractions. 2^(any number) will equal any known square. 400 is divisible by a square. I am pretty sure we are going by 180x120 right now?
That is 21,600 pixels with individual 8bits.
(Notice - This example in general doesn’t really explain the Vector engine and I am simply pointing out the average logical calculation.)
The average Arduino sketch is about 20kb. 20,000/1,000,000
With a game example drawing from our (idk 1gb)storage folder on our 4gb storage card, we should be able to draw and place 20kb of main, 40kb of blocks, 40kb of characters, 40kb of items and get 140kb. 140,000 bits / 1,000,000 bits
172.8kb + 140kb is about .32mb/1mb
We can still render the program from the SD card.
We have .7mb left and we only need .3mb for performance tbh… another .3mb to be safe.
An example of what to emulate.
You can’t run a word processor on an Arduino with only 32kb. This article speculates what must be accomplished to build an eink Arduino word processing typewriter.
I chose this project because it’s a simple illustration with pics vs a long page of physical research.
What I mean is that it shouldn’t be resized to fit our device.
It should be rewritten from scratch to fit Arduino.
It is possible with or without extra storage. We should do it ergonomically as possible. Minecraft has its own 1x1 dimensional blocks. That cube renders at a specific size - the screen size. So the screen of the device is irrelevant and also the game playing it. It runs on any JVM device.
Java -> Machine -> Device
The second build is a basic algorithm and architecture. An algorithm known as a random seed decides the environment most likely to appear. The nature of these blocks is placed around the center block. The last nature of the architecture is the location of the blocks. The location adheres after the known object has been rendered. The surrounding land is place within the decided depth with a predetermined height. You will see ground blocks < lava < diamond, so forth until ground blocks, tree objects < the sky, etc.
The first object to render is an object. The objects are trees/mobs/other land objects. The player is called onto a predetermined POV called DOF (depth). It tells the computer how much to process at once. With only 21.6kb, we should only see as far as a Minecraft house (desktop/laptop/tablet).
Any more than our immediate area should be placed onto storage.
Controls may resemble the Tamagotchi with a layout of Pokemon. However, we can have an options button. Looking around will be uncomfortable. We must see through the eyes of the Doom '93 player. Looking up or down by force. Crouching will be a chore. Hunters of diamond will be master arcade players…
Game dev is far from my forte, so you probably have a much better understanding than I do of that concept. haha
As an aside…the IEEE Spectrum website is such a mess. Early 2000’s era full screen ad with “Continue to site” button, menus and headers jitter around like a caffeine addict while scrolling, just a mess. For a body that develops standards, they sure do come up short on their own website. “Physician heal thyself!”
I don’t understand game dev tbh. I’m a very practical Roboticist.
I’ve heard and read about these guys who use triangles like ternary…as if that makes sense.
I’m talking about using the individual pixels and forming squares to build objects.
We can mathematically build an object and then move it around on screen using coordinates.
I have never actually tried. I’m much less interested in the cyber world than some. Circuitmess is something like me. We prefer the circuit part for a crucial reason. 1 because proper training is important. 2 being able to apply that training. 3 adequately adapt that training in the future. You(being the qualified example) would not like it very much if you took ‘civilians’ on an exploration mission of the outer Sol system and take test liquid caps of Pluto. It would be a long journey with ‘dumb’ people. They would be no actual help. I would expect Starfleet minimum.
Your profile says “Software Developer”? What do you do? I know a lot of people who write websites. It sounds expensive/annoying though. I had a friend who was so busy, he deleted his facebook to make up time for lost employees. He couldn’t pay them eventually…had a hard time finding clients.
I was re-reading this post recently and had a few follow-up thoughts/notes for ya:
Screen size is actually 160x128px 16bit RGB and can operate between 25 and 50fps
The controller Ringo is based on is dual-core 32-bit 160Mhz, 4MB EEPROM*** and a full 512kb of SRAM
*** The 4MB flash EEPROM is partitioned using the min_spiffs scheme, which uses a dual OTA partition setup (this allows for the Ringo loader to actually load up apps, boot into the app, and then return to the Ringo loader later). Each OTA partition is 1,966,080 bytes in size
So, you’ve got just under 2MB of flash to load the game engine and logic into, along with whatever media assets you don’t want to load from SD. Depending on the complexity of the game logic and related libraries, you might only have room for a splash screen in the bin. Loading from SD will certainly be slower, but having 512kb of RAM and dual cores does allow you to load assets into RAM behind the scenes - pinned to its own core, separate from the core the game is running logic/engine on - while playing the game.
My WiFiTest app is already at 1.4MB and I’ve only added two full screen static images (and a few very small sprites) as PROGMEM. Granted, a chunk of that is due to the MAKERphone library that needs included to most readily interact with the Ringo hardware…unless you want to write all your own functions for accessing buttons/LCD/sound/etc and not be able to receive calls/SMS while in-game. This is why I suggest employing a vector engine. The storage needed to specify “draw a line starting here and ending here” is far less than “draw this dot, now this dot, now this dot, now this dot” ad nauseam…vectors effectively compress the data needed to recreate the graphic (most of the time, anyway).
I get the mentality behind the Java approach to things, but have you ever taken a look at how much RAM a JVM can consume on a machine? Even lean JVMs have pretty hefty resource needs because it’s an abstract virtualization layer in order to retain hardware agnosticism. You’d never get anything even close to a decent JVM running on this hardware…at least not for a game (maybe a highly specialized app of some sort with a custom tiny JVM built around it, but you’d likely still need to leverage the full 4MB EEPROM to fit it).
While Ringo’s “NES controller-like” button layout is ok for some games, I agree it would be less than ideal in a type of game like Minecraft/Doom…but we do have the full keypad available too. I image that you could use the joystick as “left-hand” movement and the keypad like a “right-hand” D-Pad, allowing 8-way looking, with #5 to acting as a redundant A-Action button. You could have the keypad serve a second purpose at the same time…press * or # followed by a number to select a weapon or item in your inventory, for example.
Or you could go all out, implement the Bluetooth library and allow for basic gamepad support. haha BT is surprisingly easy to work with, as it is a serial connection at its core.
I recently took a deep dive into images in Arduino/Ringo apps for another user here:
More to your point, using ASCII versus well-optimized BMP/Sprite images would make the game a little smaller, but as I mention in the post above, BMP/Sprite image is just a BYTE per pixel representation of the color data to create it. 0x0000 is a black pixel. If you strategically leverage the two storage mediums and smart asset slicing - SD for large less frequently changed objects like levels/backgrounds and leveraging sprite layering in a clever fashion & small sprites in PROGMEM for things like your character and animations - you can build a game that is pretty robust in assets without sacrificing too much performance in the process.