Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

beckman101 writes "Gameduino is a DIY game platform built on a shield for the Arduino. It's open source hardware (BSD and, for the code, GPL). Okay, that's fairly cool. But what makes this project special is that this inexpensive board has hardware that's capable enough to be interesting. The result is a lo-fi game console built on an FPGA that gives you retro graphics without being, you know, too retro. Games actually look good."

If someone made a Minecraft for the device, I could buy it. The current codebase is way too heavy for the type of game it is - it doesn't even check if you should see an object, it just draws everything anyway. Make a lightweight version of Minecraft and it's perfect!

I'm pretty sure that adding occlusion culling would increase the size of MC's codebase, not decrease it. The issue isn't that MC has too many lines, it's that certain useful technical tricks are missing.

Depends on how fast the device(plus whatever i2c master is controlling it) can generate new sprites, I suppose.

Since the display is actually 2D, the camera's view of the 3D scene could be represented as a collection of sprites generated from the surfaces of the 3D polygons by the perspective-appropriate transformation...

Given the relatively low ceiling on number of sprites, and the fairly limited RAM and computational capacity of the arduino, you might well have real trouble getting good 3D; but I can

It's not the graphics output speed that would be the limiting factor, it would be calculation of the actual 3D scenes. I expect even running Wolfenstein would be pushing it to its limits. With the memory limitations you'd probably have to do with very very basic textures if any, and without an FPU it would be very slow to calculate the movement and rotation of a lot of vertexes.

I certainly wouldn't argue with the contention that this device(especially if paired with one of the more limited Arduino boards) would be a very limited 3D device. Getting it to do 3D would be a bit of a hack, and you would be severely limited in scene complexity(and quite possibly refresh rate) if you wanted to do any real 3D. I just wanted to argue that it would be better than completely useless, just challenging and limited for the reasons you describe...

Actually I saw a really interesting level for LittleBigPlanet2 where the guy had hacked the 2D gameworld into a very basic FPS that drew everything by painting sprites on the screen. You could only turn at 90 degree angles, everything rendered very slowly, so obviously not exactly the best gaming experience ever, but it was incredibly clever.

I guess you *could* render a scene entirely on the host controller then upload it to sprite memory when it's ready - use the gameduino just as a frame buffer. It would be limited to a four color image though.

Occlusion culling in a dynamic game world like minecraft is not trivial. Would you be willing to put up with pauses every time a block is placed or destroyed while the bsp trees are regenerated? I believe minecraft does occlude blocks that are completely walled in by opaque neighbors so you would really just be eliminating interiors anyway. With today's hardware you are often better off dumping triangles on the video card than burning cycles trying to decide what you can get away with occluding.

The trees don't have to be regenerated but rather updated. It's not that difficult with kd-trees. Surely, it's not optimal, but can give reasonable results.

New hardware supports occlusion testing on the GPU. There's a query method to test how many or if any fragments were actually drawn between the beginning of the query and its end. You can then hierarchically draw bounding boxes and only actually draw the geometry you want.Check this [nvidia.com] out.

On the Nintendo Entertainment System, data between the CPU and the PPU was pushed through an 8-bit parallel port whose practical maximum was 1 byte per 8 CPU cycles, or about 224 kB per second. That'd be fine, except all transfers had to finish during vertical blanking, the 8% of the time that the PPU was resting between frames. There was a faster hardware-assisted copy that could push 256 bytes in 512 cycles, but it worked only for OAM (sprite display lists), not background maps or graphical tiles. If this

I don't think bandwidth is an issue in this design. I mean, once the initial data is copied to the RAM on the gameduino, how much really has to change per frame for the average sprite based game with a scrolling background? If you're just scrolling horizontally, you only need to change less than 40 bytes for each 8 pixels moved, and updating the coordinates and character mappings for a few sprites isn't exactly a massive task, nor is checking for collisions as it's hardware based.

It's pretty beefy (especially for the price) - 330MHz or thereabouts, 32MB of RAM, 4gig of flash. Not sure of the exact framerate it gets in Neo Geo emulation but it looks pretty smooth on most games. This video [youtube.com] shows some gameplay.

Deleting both the YouTube and Google cookies worked. but their HTML5 playback in H.264 no longer works in Safari. Are they starting to sabotage H.264 support on YouTube to try and push WebM? Safari doesn't do WebM and I deleted Flash from my system. Vimeo works fine in HTML5, in fact better than YouTube (when it used to work, for the handful of videos that had HTML5 support to begin with).

It's an FPGA on there with verilog code available. Go grab the Xilinx WebPack (free, windows/linux), get a JTAG cable (I've seen Xilinx USB-clones for less than $50 on eBay) and get cracking.

Getting to know the tools is hard, learning to think in VHDL/Verilog is hard (at least if you're not used to thinking in terms of logic gates and other hardware) but you can transform that board into pretty much any hardware you'd like and control it from the arduino. The reason for the 400x300 is probably memory limita

Games need the caracter map to be able to display full-colour tiles, using several palette, features truckloads of sprites (up to 256) collision detection, etc.(==the equivalent of rather good console/arcade video chip of the late-8bit to 16bit era)

That's purely overkill for debugging, where one only needs to display ASCII (a 256 character set of monocrhome tiles - no palettes, except maybe for selecting a different foreground colour on specific charact

It's arguably overkill for debugging purposes, since the Arduino already has USB -> serial support for communication with a computer(and on the bench, you'll have your computer, and in the field, a cheap 'n nasty laptop just new enough to have a USB port and run a terminal emulator will be cheaper and more battery powered than just about anything that accepts VGA input), or a logic-level Rx/Tx for chatting some more basic serial device, or can drive an HD44780 display with 6 pins(fewer if you snag one of

does this really provide better capabilities than what is possible with homebrew

This won't get you sued, unlike homebrew where Nintendo and Sony routinely sue companies that deal in homebrew-related hardware. If the video can be redone into more consumer-electronics-friendly formats (composite, S-Video, component), it might even be possible to use this as a platform for developing and selling your own standalone TV games [wikipedia.org].

This won't get you sued, unlike homebrew where Nintendo and Sony routinely sue companies that deal in homebrew-related hardware.

It's interesting that this list doesn't include Microsoft. I know there to be a homebrew scene at least on the original Xbox. I imagine there to be less of one on the 360 (XNA aside) but I've never even looked into it so I honestly have no idea. I can't recall anyone ever getting into trouble for using the official XDK, although there were plenty of hoops jumped through for the sake of avoiding such unpleasantness... and because I don't recall doesn't mean it didn't happen.

It's interesting that this list doesn't include Microsoft. I know there to be a homebrew scene at least on the original Xbox.

Hence present tense. In the past tense, Microsoft was one of the companies that sued Lik Sang out of existence.

I imagine there to be less of one on the 360 (XNA aside)

As I understand it, the far smaller 360 homebrew scene is due to XNA and Media Center Extender. XNA is an official way to make and sell homebrew games, and MCE does much of what the Xbox version of XBMC did.

This is an open platform, with a great software interface. Complete documentation that is written by the guys who made it (not some reverse-engineered stuff).

Also, try to homebrew on a NES. Guess what? You also need a cartridge with some FLASH memory on board. Those are not free. I would imagine that the homebrew "development kit" is not nearly as polished as the Arduino & Gameduino.

Also, try to homebrew on a NES. Guess what? You also need a cartridge with some FLASH memory on board.

You really can't just ZIF an EEPROM? You can get a prom burner for like ten bucks. You can get a ZIF for about that. You can get an iron for about ten bucks. You can get a NES for about ten bucks. You can get solder and braid for about ten bucks. IIRC this shield is about fifty bucks and you still need some kind of Arduino to attach it to. Either way you need some kind of PC, too. Anyway I'm not suggesting that this device has no purpose, I'm asking if this device has no purpose.

And using a SPI interface to control it is like using Lego as a drive train from the V8 to the rest of the car.

But, you see, anything with Arduino in the name is instamagically popular. As stupid as using an Arduino is, this project has a much bigger chance of success as an Arduino shield than as a standalone board.

I'm too lazy to check, but I'm willing to bet there are Arduino shields out there that only use the Arduino for power.

The asteroids page [excamera.com] claims that a game uses a set of four push buttons (left, right, up, fire). This means an Atari 2600 joystick or a Sega Genesis gamepad would likely work with the appropriate connector, as those are electrically similar in a way to a set of common-ground push buttons. Or an NES or Super NES controller could be connected as an SPI slave.

Just because it uses the same connection doesn't mean the SEGA Genesis gamepad isn your typical dumb switches Atari-style joystick. It uses a 74HC157 internally.

My point was that the Gameduino should have specified an interface from the start to simplify the whole thing. Some people will go with an Atari interface, others with a SNES interface, and so on... Games will be compatible on everything except controllers, which is kind of dumb since it's the easiest part to do.

We're talking about a processor that can reach up to 66MHz. Which isn't too stellar from the point of view that we share today concerning Processor speed, but consider:

No need for a heavyweight OS (no need for multitasking, no need to consider other programs running).No need for a hypervisor or other DRM (seriously, nobody but the maker of commercial software wants it)No need for "generalist" hardware (just plug in the hardware your current game needs).