Post screenshots of stuff you're working on!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Post screenshots of stuff you're working on!

«‹›203 »

hendersa: Sep 17, 2006

Suspicious Dish posted:

I want to read that book. If I buy the book, will you get royalties or paid in some way? I want to make sure you get some cash for all this effort.

I will get a dollar or two for each book that is sold. People don't get rich writing books like this, particularly with an audience as small as the BBB market. You won't be compensated very well at all for all of the time that you spend on it. But, I always wanted to write a book and I actually enjoyed writing it, so there you go. I also spent way too much time drawing diagrams:

I hated drawing those diagrams so much.

# ? Nov 25, 2014 20:15

Adbot: ADBOT LOVES YOU

# ? Apr 25, 2024 21:37

Scaramouche: Mar 26, 2001; SPACE FACE! SPACE FACE!

I used to write tech books for McMillan Press (think "learn (x) in 30 days!" where x = some web development technology) and yeah, you don't get rich doing it; all the money is in the advance, not the royalties. But what they are awesome for is resume padding, interview padding, and 'SEO' internet paper trail. hendersa can you say which publisher?

# ? Nov 25, 2014 20:23

hendersa: Sep 17, 2006

Scaramouche posted:

I used to write tech books for McMillan Press (think "learn (x) in 30 days!" where x = some web development technology) and yeah, you don't get rich doing it; all the money is in the advance, not the royalties. But what they are awesome for is resume padding, interview padding, and 'SEO' internet paper trail. hendersa can you say which publisher?

Sure. It is Packt Publishing. Nice folks to work with.

# ? Nov 26, 2014 06:36

blorpy: Jan 5, 2005

hendersa posted:

I don't have a centralized location for this stuff. I should probably start a thread in the project log forum...

BeagleSNES started as a class project for a graduate course in embedded system design. My goal was to turn the BeagleBoard-xM ARM-based SBC into a stand-alone Linux appliance that mimicked an SNES. I started by building the SNES9X emulator on that platform, but I quickly found out that the kernel was missing some things that I needed. I ended up hacking on the bootloader and kernel a lot:

I customized the OS a bit and profiled/optimized the emulator for optimal performance. To make the system more appliance-like, I wrote a GUI front-end for it. I also wrote a 35 page manual to turn in for the project's final report. I ended up getting an "A".

Time spent at this point: 4 months.

I had a random person mail me and request that I port my work to this new BeagleBone Black board that was coming out. The BBB was a third of the cost of the BB-xM and had a higher clock speed, so he was eager to play SNES games on the thing. I told him that I'd think about it, and then he Paypal'd me some money and requested that I went to go buy one ASAP. So, I felt guilty and got to work.

A guy from TI contacted me and requested a bunch of features (second controller, better front-end GUI) so that he could show it off at an internal event:

Done and done. Time spent at this point: 10 months.

Some TI interns contacted me and asked for my help in making BeagleSNES portable. I fixed a few bugs and added some options to make it portable. They designed a portable unit based on it:

Time spent at this point: 12 months.

I made my own version using standard BeagleBone capes:

Time spent at this point: 14 months.

Around this time, I had the bright idea to spend some time getting Android running well on the BBB using more recent kernels. I sunk about six months into setting up build processes and answering thousands of mails on how to do it. I still maintain a BBB port of the Android Open Source Project for the BBB (bbbandroid.org). I also wrote a few magazine articles on the BBB.

Time spent at this point: 18 months.

Around the holidays, I pushed out another BeagleSNES release with a better GUI and some bug fixes.

Time spent at this point: 22 months.

I began playing around with augmented reality (AR) stuff with an eye towards augmenting an emulator with AR for use on the BBB (once the kernel's hardware-accelerated OpenGL ES worked again):

I asked via the BeagleBoard community about moving the BBB features from the older, stable kernel (3.8) to newer ones (3.13, 3.14). I was laughed at and told to "do it myself". I began hacking on the newer kernels to retrofit cape overlay support into it. I showed that it worked and was told to stop, since others were working on it and trying to get it into the mainline kernel. To this day, I think I'm the only one with a 3.13 kernel with cape support in it. And it's mine. ALL MINE.

Time spent at this point: 27 months.

I hacked in savestate and GPIO input support for BeagleSNES. The manual was up to about 50 pages by this point.

I began designing a controller cape that would turn the BBB into a proper video game console:

I also began looking at other emulators (VBA-M and FCEUX) and rolling them into the codebase. Unfortunately, VBA-M and FCEUX are GPL and SNES9X has its own license, so they can't all live in the same codebase. I realized I'd have to break it out into an emulator for GBC, GBA, and NES that also could spawn another process for SNES.

I also wrote and presented a research paper at the International Symposium on Software Testing and Analysis. The paper shows a software framework that I developed that uses whole-system emulation to analyze malware samples:

http://lcs3.syr.edu/faculty/yin/pubs/issta14.pdf

In the very loosest sense, you can say that I'm getting a PhD in emulation. For all those family members that said that I was wasting time playing video games all of those years: Suck it.

Time spent at this point: 30 months.

I experimented with a variety of different BBB kernels and began sending back patches and bug reports to fix various things. I really wanted to get OpenGL ES working on that thing. I started hacking together my texture mapping stuff for hardware scaling with OpenGL ES.

An acquisitions editor for a publisher sent me a mail out of the blue and said that his company would like me to write a book on Android and hardware interfacing on the BBB. I didn't have time, but I agreed anyway because I am an idiot. I wrote that whole drat book in six weeks. I'd work all day, come home, and then write for four to five hours each night. I'd get about 20 hours of writingin in each weekend. Rough drafts are in to the editors and are out for technical review right now. It will probably be out in print in January. Here is the example circuit from chapter 6:

Time spent at this point: 34 months.

And here we are. I don't know about you guys, but I feel really drat tired. I need a nap.

Oh, this is awesome! Are you taking any stimulants, by the way? Care to endorse any?

# ? Nov 26, 2014 07:31

ShaunO: Jan 29, 2006

Thanks for sharing your timeline there hendersa, it's quite inspiring.

# ? Nov 26, 2014 08:39

Centripetal Horse: Nov 22, 2009; Fuck money, get GBS

This could have bought you a half a tank of gas, lmfao -
Love, gromdul

hendersa posted:

I don't have a centralized location for this stuff. I should probably start a thread in the project log forum...

You should do this. So few projects make it this far before sputtering out that it's fascinating to watch one that keeps chugging along month after month. This is definitely one of the coolest things I've seen around here.

hendersa posted:

I ended up hacking on the bootloader and kernel a lot:

I customized the OS a bit and profiled/optimized the emulator for optimal performance.

Did you modify and compile a complete custom kernel and/or bootloader, or was it more about feeding them the right options and loading the right modules? From what you say later in your post, I am guessing there was significant custom code added to the kernel.

hendersa posted:

Some TI interns contacted me and asked for my help in making BeagleSNES portable. I fixed a few bugs and added some options to make it portable. They designed a portable unit based on it:

By this, do you mean making the software portable to different hardware platforms, or something else?

hendersa posted:

I made my own version using standard BeagleBone capes:

I asked via the BeagleBoard community about moving the BBB features from the older, stable kernel (3.8) to newer ones (3.13, 3.14). I was laughed at and told to "do it myself". I began hacking on the newer kernels to retrofit cape overlay support into it. I showed that it worked and was told to stop, since others were working on it and trying to get it into the mainline kernel. To this day, I think I'm the only one with a 3.13 kernel with cape support in it. And it's mine. ALL MINE.

I began designing a controller cape that would turn the BBB into a proper video game console:

I am not familiar with the term cape. It seems to refer to expansion/controller boards. Do I have that right? What is your idea of "proper?" Are you talking about creating something to accept original SNES controllers, or just something that will be a permanent part of the board, or none of the above?

hendersa posted:

I also began looking at other emulators (VBA-M and FCEUX) and rolling them into the codebase. Unfortunately, VBA-M and FCEUX are GPL and SNES9X has its own license, so they can't all live in the same codebase. I realized I'd have to break it out into an emulator for GBC, GBA, and NES that also could spawn another process for SNES.

In the very loosest sense, you can say that I'm getting a PhD in emulation. For all those family members that said that I was wasting time playing video games all of those years: Suck it.

I'm not sure if I am visualizing this properly. When you say a "separate process," are you just talking about your GUI calling one emulator for X, Y, and Z, and another for SNES? Is there more to it than that?

It sure sounds like you're gathering quite a bit of knowledge on the subject. I've always been fascinated by emulation, but I've never taken a stab at it, myself. I have no formal education, and taught myself various flavors of BASIC and then C++ as a kid. Since then, I've worked in many languages on many projects, but I've always felt I was lacking some of the learning I needed to really dive into the heavy stuff. That makes your project extra interesting to me.

hendersa posted:

I experimented with a variety of different BBB kernels and began sending back patches and bug reports to fix various things. I really wanted to get OpenGL ES working on that thing. I started hacking together my texture mapping stuff for hardware scaling with OpenGL ES.

Is this a matter of putting glue into the emulator code to work with native hardware capabilities? Does that hamper portability significantly?

This is very cool, I appreciate the lengthy write-up. I hope you do put up a log or something so we don't have to wait until you remember to fill us all in on the latest news. This project deserves its own place, where you can post all the minutia for us busybodies to nose around in.

# ? Nov 26, 2014 09:51

hendersa: Sep 17, 2006

Markov Chain Chomp posted:

Oh, this is awesome! Are you taking any stimulants, by the way? Care to endorse any?

Just coffee. My coworkers affectionately refer to the coffee that I drink as the "black death": I always drink it black, it is enough to keep you up at night, and it is powerful enough to kill most Europeans. When my heart finally explodes, I think that it will probably take out the surrounding city block.

ShaunO posted:

Thanks for sharing your timeline there hendersa, it's quite inspiring.

Centripetal Horse posted:

Did you modify and compile a complete custom kernel and/or bootloader, or was it more about feeding them the right options and loading the right modules? From what you say later in your post, I am guessing there was significant custom code added to the kernel.

I modified the bootloader to display a splash screen immediately upon powering on the platform. I did this by taking a running Linux system with the framebuffer initialized and then using debugfs in the kernel to dump all of the video register settings. I then hardcoded those settings into the bootloader, along with a static buffer of image data that I copied directly to the memory-mapped framebuffer in memory. The system pops on and you have a splash screen. Unfortunately, this was only valid for the old "VENC" NTSC analog video that I used in the very first version of BeagleSNES. Since then, the bootloader mods have been hard-coded defaults to reduce timeout values and get the system up and running ASAP.

On the kernel side, I've hacked a few things in there to make life easier. For example, the HDMI standard only supports audio over the HDMI cable at certain resolutions (720x480, 1280x720, 1920x1080). But, if you don't have a display connected to the BBB when it boots, the stock framebuffer driver defaults to 1024x768. BeagleSNES is intended to be plugged into your television, so this didn't make sense. Sure, most digital TVs support 1024x768, but what about audio? So, I hacked on the framebuffer driver guts to default to 720x480 if no display is plugged in at power-up time. When you do plug in the display after the system boots, you get the correct 720x480 and audio.

There was also this problem with USB hotplugging where you either had the gamepads plugged in at boot or you were out of luck. Official kernel patches came along to fix this later, but for a while I was coming up with user space workarounds and experimenting with resetting the USB hub inside of the USB drivers in the kernel. I fixed or came up with workarounds for a lot of issues when the BBB first came out.

I've also spent hundreds of hours recompiling and profiling the kernel in different configurations to reduce its size, reduce boot time, improve performance with different scheduler and governor combinations, and statically including features to reduce the number of kernel modules loaded at runtime.

I just love it when someone posts on a forum somewhere saying that he/she doesn't see what the big deal is because all I did was "recompile SNES9X for the BBB." I then close my eyes, take off my glasses, pinch the bridge of my nose, let out a big sigh, put my glasses back on, and get back to looking through kernel code.

quote:

By this, do you mean making the software portable to different hardware platforms, or something else?

That is "portable" as in "I want a battery-powered hand-held SNES that I can play while I stand in line."

quote:

I am not familiar with the term cape. It seems to refer to expansion/controller boards. Do I have that right? What is your idea of "proper?" Are you talking about creating something to accept original SNES controllers, or just something that will be a permanent part of the board, or none of the above?

Capes are the modular add-on boards that plug into the big P8/P9 pin connectors on the BeagleBone boards. They are like Arduino shields, in a way. A proper cape has an EEPROM chip on it that talks via I2C to the BBB to say "I am cape board XXXX version YYYY, please load the proper device tree overlay and drivers to support me" to the kernel capemgr subsystem. This makes the cape "plug and play." You plug it into a powered-off BBB, turn it on, and it just starts working. For the design that I was looking at, I wanted to add a watch battery-backed real-time clock (to keep time for battery-backed games like Pokemon Yellow) and two SNES controller ports. Since NES, GBC, and GBA all use a subset of the SNES controller buttons, SNES controllers are the lowest common denominator.

quote:

I'm not sure if I am visualizing this properly. When you say a "separate process," are you just talking about your GUI calling one emulator for X, Y, and Z, and another for SNES? Is there more to it than that?

Think of it as two programs. The first program has the GUI and the NES, GBC, and GBA source code built into it. I took the code for all of them and mashed them together into a single binary. The second program is the SNES emulator without the GUI frontend. The first program lets you select the game via the GUI and play the non-SNES games. If you select an SNES game, the GUI launches the SNES emulator and then the GUI hangs out quietly in the background while the SNES emulator takes the foreground and does its thing. Some logic needs to be duplicated in the SNES side, such as reading the button mapping configurations out of the XML file and implementing the pause/savestate dialog.

For the Unix-inclined, this is implemented using fork() and execve() for the SNES emulator process spawn and a waitpid() on the GUI to watch for the SNES emulator to exit. It is similar to how shells launch new processes. You can use system() to launch it, but you don't have the fine-grained control over it that you do with the fork/execve combo.

quote:

Is this a matter of putting glue into the emulator code to work with native hardware capabilities? Does that hamper portability significantly?

I spend a lot of time running the emulators and profiling the code. I then tune it specifically for these particular boards, so I guess that it probably does impact portability a bit. I can still run it all just fine on the Linux VM on my x86 laptop, though. Some common changes are:

- Ripping out code for unneeded functionality (movie recording/playback, emulation speed controls, etc.).
- Inlining functions and using global or register variables to pass parameters, rather than stack-based stuff.
- Allocating buffers once as globals and then reusing them to avoid the memory allocation performance impacts.
- Hardcoding resolutions and bypassing scaling blitter logic.
- Using the "register" keyword all over the place.

quote:

This is very cool, I appreciate the lengthy write-up. I hope you do put up a log or something so we don't have to wait until you remember to fill us all in on the latest news. This project deserves its own place, where you can post all the minutia for us busybodies to nose around in.

I usually have updates in bursts, but I'll think about setting up the log and trying to smooth out the update interval a bit. Sometimes, I get so busy doing things that I don't have time to tell people about them! :science:

# ? Nov 26, 2014 16:55

leper khan: Dec 28, 2010; Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

hendersa posted:

Thanks for being awesome and making the rest of us look bad for not being awesome. Looking forward to the project.log.

# ? Nov 26, 2014 17:09

Mr. Glass: May 1, 2009

hendersa posted:

really jealous of your handwriting and super clean schematics. all of my notes look like disgusting scribbles

# ? Nov 26, 2014 17:22

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

hendersa posted:

Can you give us a breakdown of what your day-to-day work is, too? I swear you've put enough effort into this that this might as well BE your day job, but I'm guessing it isn't paying. Though maybe it's leading to that. Or, er.

Basically does this tie into future career goals? Does it fit with whatever you do right now? Or is this just a hyper crazy evening and weekends project that's amazingly amazing?

# ? Nov 26, 2014 18:01

hendersa: Sep 17, 2006

Shalinor posted:

Can you give us a breakdown of what your day-to-day work is, too? I swear you've put enough effort into this that this might as well BE your day job, but I'm guessing it isn't paying. Though maybe it's leading to that. Or, er.

Basically does this tie into future career goals? Does it fit with whatever you do right now? Or is this just a hyper crazy evening and weekends project that's amazingly amazing?

I am currently a PhD student, but I am funded by an external lab doing research work for government organizations like the Air Force and DARPA. So, about half of the time I am at the university doing research and the other half I am at an office doing research. The work is quite similar in both cases: reading papers, writing code, taking measurements, and then writing papers. Prior to being externally funded, I was funded by my department and would teach undergrad classes. I really enjoyed teaching and I hope that I have an opportunity to do it again sometime in the future.

My work on the various Beagle SBCs is only tangentially related to my lab work, so it is mostly all just hobby project work done in the evenings and on weekends. It does have its perks, though. I'm certainly building up a bunch of know-how and street cred, and I've had several hardware manufacturers send me complementary equipment and component samples for experimentation and compatibility testing with my kernels and software. Some very nice folks with a lot of expertise send me mail now and then to toss ideas back and forth. People will also occasionally just donate money to me, which I'm always very surprised to see and thankful for (and which I spend on better equipment and books and doughnuts), and I get a lot of mails offering consulting/writing opportunities and embedded system engineering jobs. There is certainly potential to just take on this sort of work full-time.

I put a lot of time into these projects because I really enjoy it. Since you a game developer, I bet that you know exactly where I'm coming from. We could be coding database backends or something for a living, but we grind away at what we do because we like it so much.

# ? Nov 26, 2014 21:45

hendersa: Sep 17, 2006

I don't want to spam the poor screenshot thread any more, so I opened up a project.log thread (my first SA thread!) for all of this stuff. Please feel free to post your questions and ideas about the things that I am working on over there so that we can get back to seeing screenshots of the awesome stuff that everyone is working on. :science:

# ? Nov 26, 2014 22:33

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

hendersa posted:

I don't want to spam the poor screenshot thread any more, so I opened up a project.log thread (my first SA thread!) for all of this stuff. Please feel free to post your questions and ideas about the things that I am working on over there so that we can get back to seeing screenshots of the awesome stuff that everyone is working on.

Please maybe sometimes post here too because seriously your work is awesome. Not sure anyone is ever annoyed by you posting COOL poo poo, heh.

(and yep, I totally understand - I'm a game dev, and the whole way we even get into this industry is nights and weekend work on portfolio projects)

# ? Nov 26, 2014 22:46

Scaevolus: Apr 16, 2007

hendersa posted:

- Using the "register" keyword all over the place.

I thought modern compilers ignored 'register' entirely, barring GCC's register variables extensions.

# ? Nov 26, 2014 23:01

Centripetal Horse: Nov 22, 2009; Fuck money, get GBS

This could have bought you a half a tank of gas, lmfao -
Love, gromdul

hendersa posted:

BeagleBone Badassery

Argh! I have so many more questions. I am starting to fear that you will die of exhaustion if I keep questioning you, because you reply so thoroughly. I will keep the additional questions to myself. Thanks a lot for the replies, your project is endlessly interesting to me. I can't wait to see what you do with it, next. I would also love to see a fully portable version. If I manage to find work before I end up living under a bridge, I want to take a crack at assembling one, myself.

I know you're busy doing instead of talking, but I am certain I am not the only one who would follow a dev log or any other documentation you choose to keep on this project.

Edit: Oh, you opened a project log thread. Very cool.

# ? Nov 26, 2014 23:07

hendersa: Sep 17, 2006

Scaevolus posted:

I thought modern compilers ignored 'register' entirely, barring GCC's register variables extensions.

I was using it in the tile rendering code in the SNES9X codebase. I don't have the code in front of me, but I was using something like this:

https://gcc.gnu.org/onlinedocs/gcc/Local-Reg-Vars.html

If I remember right, I was using r12 because the compiler assumes that it is going to get trashed between function calls (per the ARM EABI), so you can generally use it in loops that aren't calling functions.

# ? Nov 26, 2014 23:39

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Scaevolus posted:

I thought modern compilers ignored 'register' entirely, barring GCC's register variables extensions.

Besides the gcc extension that hendersa is talking about, the standard 'register' keyword (though probably ignored by the optimizer) isn't a complete no-op - it makes it an error to take the address of the variable.

# ? Nov 27, 2014 00:45

Scaevolus: Apr 16, 2007

Blotto Skorzany posted:

Besides the gcc extension that hendersa is talking about, the standard 'register' keyword (though probably ignored by the optimizer) isn't a complete no-op - it makes it an error to take the address of the variable.

Not in C++!

# ? Nov 27, 2014 01:02

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

Didn't buy that until I tried it. Another item for the ol' C and C++ semantic differences trivia file.

# ? Nov 27, 2014 01:57

baka kaba: Jul 19, 2003; PLEASE ASK ME, THE SELF-PROFESSED NO #1 PAUL CATTERMOLE FAN IN THE SOMETHING AWFUL S-CLUB 7 MEGATHREAD, TO NAME A SINGLE SONG BY HIS EXCELLENT NU-METAL SIDE PROJECT, SKUA, AND IF I CAN'T PLEASE TELL ME TO
EAT SHIT

hendersa posted:

I don't want to spam the poor screenshot thread any more, so I opened up a project.log thread (my first SA thread!) for all of this stuff. Please feel free to post your questions and ideas about the things that I am working on over there so that we can get back to seeing screenshots of the awesome stuff that everyone is working on.

You should still post screenshots though, especially gifs because who doesn't like those?

And yeah I'm not too sure about the exact performance benefits of ES 2.0 (or above) here, but if you're inclined the shader pipeline stuff is actually pretty simple when you're just rendering textures to quads, and I'm getting the feeling you could get up to speed and bang out some comprehensive benchmarks in like, 15 minutes or something :v:

I don't know if it'll help or if you can make use of it, but there are some example programs here you might be able to benchmark with, at least comparing ES 2.0 FBOs with the 1.0 extensions:
http://processors.wiki.ti.com/index.php/Render_to_Texture_with_OpenGL_ES#Render_To_Texture
Or maybe not, but it's a nice page anyway!

# ? Nov 27, 2014 10:30

hendersa: Sep 17, 2006

baka kaba posted:

You should still post screenshots though, especially gifs because who doesn't like those?

And yeah I'm not too sure about the exact performance benefits of ES 2.0 (or above) here, but if you're inclined the shader pipeline stuff is actually pretty simple when you're just rendering textures to quads, and I'm getting the feeling you could get up to speed and bang out some comprehensive benchmarks in like, 15 minutes or something

I don't know if it'll help or if you can make use of it, but there are some example programs here you might be able to benchmark with, at least comparing ES 2.0 FBOs with the 1.0 extensions:
http://processors.wiki.ti.com/index.php/Render_to_Texture_with_OpenGL_ES#Render_To_Texture
Or maybe not, but it's a nice page anyway!

Thanks! I actually have seen this already, and all of the code for the examples comes with the PowerVR SDK that contains the binary blob libraries, system daemon, headers, and kernel module code for the SGX video drivers. This code is based on the PowerVR shell framework, which PowerVR supplies to make developing SGX-based OpenGL ES apps "easy". The shell framework is to SGX OpenGL ES apps what GLUT is to OpenGL. You just tell it "open a window", "load this shader", etc. and it handles the rest. I don't use the shell because it hides too many things from me that I need to handle myself.

The code is handy as a reference for a few aspects of binding the textures and FBOs and whatnot, but I'll have to spend some time digging through the PowerVR shell code to discover any other parts of the process that the shell is abstracting away from me.

# ? Nov 28, 2014 02:21

Id4ever: Dec 2, 2004

Race Day

A realtime multiplayer racing game I've been working on for the last 14 months or so. Should be in the App Store and on Google Play by 4 December.

# ? Nov 28, 2014 14:35

lord funk: Feb 16, 2004

Id4ever posted:

Race Day

A realtime multiplayer racing game I've been working on for the last 14 months or so. Should be in the App Store and on Google Play by 4 December.

Oh man getting Dirt Bike vibes from this. Nice!

# ? Nov 29, 2014 22:31

Ferg: May 6, 2007; Lipstick Apathy

Id4ever posted:

Race Day

A realtime multiplayer racing game I've been working on for the last 14 months or so. Should be in the App Store and on Google Play by 4 December.

Are you planning on Android TV support? It looks like it would be pretty killer on there.

# ? Nov 30, 2014 00:47

Id4ever: Dec 2, 2004

Ferg posted:

Are you planning on Android TV support? It looks like it would be pretty killer on there.

For now we're targeting phones and tablets. But a split-screen mode for Android TV would be fun to add. It's not something we've planned though. Would probably have to wait and see if the game is a success first (and if Android TV catches on).

# ? Nov 30, 2014 01:37

crazysim: May 23, 2004; I AM SOOOOO GAY

Id4ever posted:

Race Day

A realtime multiplayer racing game I've been working on for the last 14 months or so. Should be in the App Store and on Google Play by 4 December.

Oh man it's like that rock crawling/time trial app I spent hours playing with on with my Mac.

edit: Hmm? Is December 4 the release date or is it blocked in the US to gate the release? It looks to be up on the Google Play store.

crazysim fucked around with this message at 02:09 on Nov 30, 2014

# ? Nov 30, 2014 02:06

Claeaus: Mar 29, 2010

I love me some raytracing!

# ? Nov 30, 2014 11:13

NorthByNorthwest: Oct 9, 2012

Claeaus posted:

I love me some raytracing!

Very nice DOF!

I've been trying to put together a mysterious lake scene. I've got a skybox working with a water shader.

# ? Nov 30, 2014 12:02

Id4ever: Dec 2, 2004

crazysim posted:

Oh man it's like that rock crawling/time trial app I spent hours playing with on with my Mac.

edit: Hmm? Is December 4 the release date or is it blocked in the US to gate the release? It looks to be up on the Google Play store.

We published the game in Canada about a month ago, which is why you can see it on the Google Play website. We're releasing it globally on December 4.

# ? Nov 30, 2014 15:37

lunar detritus: May 6, 2009

I'm doing some rudimentary animations in ascii with javascript but, probably because I don't have a CS background, I feel like I'm doing it wrong and I'm not sure where to look for information. I have no problem animating things frame per frame (as it'll be necessary for some of what I have in mind) but there are things I'm sure can be generated, like waves or pulses.

# ? Dec 1, 2014 04:24

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

I like flame fractals.

Avenging Dentist fucked around with this message at 07:42 on Dec 1, 2014

# ? Dec 1, 2014 07:14

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Well now I do too!

# ? Dec 1, 2014 08:11

TheresaJayne: Jul 1, 2011

gmq posted:

I'm doing some rudimentary animations in ascii with javascript but, probably because I don't have a CS background, I feel like I'm doing it wrong and I'm not sure where to look for information. I have no problem animating things frame per frame (as it'll be necessary for some of what I have in mind) but there are things I'm sure can be generated, like waves or pulses.

When i saw that it reminded me of a video i saw from TED, that shows how data can be turned into a graphical image to allow instant visibility of what the data is. I wonder if anyone has any ideas how they do this?

http://www.ted.com/talks/chris_domas_the_1s_and_0s_behind_cyber_warfare

# ? Dec 1, 2014 08:28

LP0 ON FIRE: Jan 25, 2006; _{beep boop}

Id4ever posted:

Race Day

A realtime multiplayer racing game I've been working on for the last 14 months or so. Should be in the App Store and on Google Play by 4 December.

This looks awesome! What are you using to develop it, in terms of libraries, code and tools? Cocos2D?

# ? Dec 1, 2014 16:40

Id4ever: Dec 2, 2004

LP0 ON FIRE posted:

This looks awesome! What are you using to develop it, in terms of libraries, code and tools? Cocos2D?

Client:
- Programming in Objective-C / Xcode
- Apportable for the Android build (basically Objective-C + core Cocoa libraries ported to Android)
- Cocos2D for graphics
- Box2D for physics
- FMOD for sound / music
- R.U.B.E. for editing levels.
- SpriteBuilder for GUI layout / animations.
- TexturePacker for generating sprite sheets.

Server:
- Realtime part: custom socket server written in Go.
- Accounts / leaderboards etc: Python with Django.
- Ansible for deployment (to EC2).
- Vagrant for managing dev environments.

Id4ever fucked around with this message at 20:53 on Dec 1, 2014

# ? Dec 1, 2014 20:47

LP0 ON FIRE: Jan 25, 2006; _{beep boop}

Id4ever posted:

Client:
- Programming in Objective-C / Xcode
- Apportable for the Android build (basically Objective-C + core Cocoa libraries ported to Android)
- Cocos2D for graphics
- Box2D for physics
- FMOD for sound / music
- R.U.B.E. for editing levels.
- SpriteBuilder for GUI layout / animations.
- TexturePacker for generating sprite sheets.

Server:
- Realtime part: custom socket server written in Go.
- Accounts / leaderboards etc: Python with Django.
- Ansible for deployment (to EC2).
- Vagrant for managing dev environments.

I'm using Cocos2D too. I totally forgot about Apportable for Android stuff, so I'll have to consider it. Mine doesn't really have physics, or anything complex so I'm not using Box2D, but R.U.B.E. looks amazing. I'm just using Tiled (lol) for level editing mainly. I wish I could develop my own editor, but I just don't have the time. For audio I'm using object AL, and I nor the developer has been able to figure out how to use more than one audio context. I need this for one hit and looping sounds plus music. I just sort of quit on it, so I'll look into FMOD.

You should also check out Particle Designer and Glyph Designer.

# ? Dec 1, 2014 21:20

Id4ever: Dec 2, 2004

LP0 ON FIRE posted:

I'm using Cocos2D too. I totally forgot about Apportable for Android stuff, so I'll have to consider it. Mine doesn't really have physics, or anything complex so I'm not using Box2D, but R.U.B.E. looks amazing. I'm just using Tiled (lol) for level editing mainly. I wish I could develop my own editor, but I just don't have the time. For audio I'm using object AL, and I nor the developer has been able to figure out how to use more than one audio context. I need this for one hit and looping sounds plus music. I just sort of quit on it, so I'll look into FMOD.

You should also check out Particle Designer and Glyph Designer.

FMOD is very powerful and solid, and I would definitely recommend checking it out. For us, the way you can create engine sound models by mixing clips recorded at different RPMs and loads is just incredible, and we've got some really nice audio in Race Day because of it. They also changed their licensing model recently, so that it's now free for indies with budgets under $100k.

By the way, Race Day is now available worldwide:
Google Play
App Store

# ? Dec 3, 2014 18:22

LP0 ON FIRE: Jan 25, 2006; _{beep boop}

Id4ever posted:

FMOD is very powerful and solid, and I would definitely recommend checking it out. For us, the way you can create engine sound models by mixing clips recorded at different RPMs and loads is just incredible, and we've got some really nice audio in Race Day because of it. They also changed their licensing model recently, so that it's now free for indies with budgets under $100k.

By the way, Race Day is now available worldwide:
Google Play
App Store

Cool thanks, good to know! I just wrote to my boss about it. I remember checking it out before and yeah, it was $500. Does FMOD use OpenGL? Object AL did which made it really fast. It was also really easy to implement and of course a sound event was just one line with options to indicate pitch, volume, panning, etc.

Congrats on your game release. Can't wait to check it out.

# ? Dec 3, 2014 18:38

TastyShrimpPlatter: Dec 18, 2006; It's me, I'm the

Finished up my 4th game in as many weeks. I'm pretty happy with this one http://tastyshrimp.itch.io/week-4/

# ? Dec 6, 2014 10:55

Adbot: ADBOT LOVES YOU

# ? Apr 25, 2024 21:37

RoboCicero: Oct 22, 2009; "I'm sick and tired of reading these posts!"

It's pretty cute! Did you figure out a solution to your lights question, or did you just use deferred rendering / crank it up to like 16 pixel lights?

# ? Dec 6, 2014 19:49

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Post screenshots of stuff you're working on!

«‹›203 »