What are you working on? (Game Making Thread)
- Thread starter Ellie
- Start date
Ehg, that's bullshit. Most people don't realise that kids want to learn however kids don't want to be forced into learning.Princess Amy":10bjzc99 said:
The fact that they didn't like you learning something is why our education system sucks. Even if you were a teen at the time you had the desire to learn something, so your teachers shoulda kept shut and let you learn.
My brother got a cheap kit and he never uses it (he's 10) so I took it off his hands and taught myself, now it's my favourite instrument :lol:
I have a demo of my app on YouTube now, dubbed "The DrumLive! Project". I don't think this is too bad for two days of work
Forgot about YouTube and copyright, whoops. It's no good without an audio track.
Dropbox saves the day: here
It feels really good to actually mix my two hobbies together - Transcribing is actually surprisingly fun!
EDIT: New interface, and I just finished transcribing this song. I think I just realised how hard this will be to play. Beautiful 60fps Link
Forgot about YouTube and copyright, whoops. It's no good without an audio track.
Dropbox saves the day: here
It feels really good to actually mix my two hobbies together - Transcribing is actually surprisingly fun!
EDIT: New interface, and I just finished transcribing this song. I think I just realised how hard this will be to play. Beautiful 60fps Link
I'd like to make a project thread but there's only so much you can show with a rhythm game that lacks all menus.
Re-wrote the hit tests for improved accuracy and fixed spam exploits. Transcribed a few songs.
Primarily though, I've been messing around trying to get the midi-winmm library working on windows but it doesn't seem to want to go. Segment fault every single time.
Whats a game about drumming if you can't use your drums
Re-wrote the hit tests for improved accuracy and fixed spam exploits. Transcribed a few songs.
Primarily though, I've been messing around trying to get the midi-winmm library working on windows but it doesn't seem to want to go. Segment fault every single time.
Whats a game about drumming if you can't use your drums
coyotecraft
Sponsor
I was only suppose to configure the battler settings in the project folder and then go back to animating again. But I got distracted with scripting issues. The battle system needs to be optimized. The frame rate is really low.
I think there's a lot of stuff being updated/refreshed that don't need to be.
I like to stick print messages in places. So if it pops up once; it's good. If it's repeating I need to figure out what conditions I can add to so that it only runs that part of the script once.
I think there's a lot of stuff being updated/refreshed that don't need to be.
I like to stick print messages in places. So if it pops up once; it's good. If it's repeating I need to figure out what conditions I can add to so that it only runs that part of the script once.
Working on trying to fix bugs in a segmented LZ77 decompressor. It's supposed to run during the extra time between frames to decompress 0x1000 bytes of graphics data to be DMA'ed to VRAM, except...
Since the program counter is up in RAM, this one will be a pain to debug. Especially with the speed that Exodus runs on my ancient system. :P
Since the program counter is up in RAM, this one will be a pain to debug. Especially with the speed that Exodus runs on my ancient system. :P
Holy shit finally got frustum culling added, doesn't do much on my demo scene (Fluctuates between a loss of 5 frames to a gain of 5 frames) but that is expected, where it really shined was when I hammered as much as possible into the scene;
So I changed my spinning cube demo from 16 cubes (500fps at 720p) to 2048 cubes (18fps at 720p).
Keeping in mind that the cubes themselves are still unoptimised (I really need to get round to doing that).
When frustum culling is enabled, every time 75% of the cubes swing off-screen the frame-rate jumps from 18fps to 200fps, woo-hoo it works!
So with this I can construct the detailed geometry that is needed for the commercial project that this engine is being used in, my one concern was that we'd have all this off-screen geometry on mobile phones dragging the performance down.
So that's the result of 2 days of studying geometry maths X_X
On top of that, the Android codebase for this project no longer crashes, I re-wrote it this time studying the threads that Android dumps apps onto so I could grab the rendering thread and put everything native onto that, it's made the code more stable however there is an annoying problem with clean-up, there's no onShutDown event for Android's GLSurfaceView class so I had to make my own version that adds the shutdown command onto the GL thread, but by the time it's called the context is already trashed so GPUs spit out a warning for attempting GL calls on an invalid context, luckily everything works fine and it's just GL wind-down calls that are being attempted, using that moment to destroy my rendering engine works fine (And is fast).
Being able to rotate and close the app without it crashing feels great.
So I changed my spinning cube demo from 16 cubes (500fps at 720p) to 2048 cubes (18fps at 720p).
Keeping in mind that the cubes themselves are still unoptimised (I really need to get round to doing that).
When frustum culling is enabled, every time 75% of the cubes swing off-screen the frame-rate jumps from 18fps to 200fps, woo-hoo it works!
So with this I can construct the detailed geometry that is needed for the commercial project that this engine is being used in, my one concern was that we'd have all this off-screen geometry on mobile phones dragging the performance down.
So that's the result of 2 days of studying geometry maths X_X
On top of that, the Android codebase for this project no longer crashes, I re-wrote it this time studying the threads that Android dumps apps onto so I could grab the rendering thread and put everything native onto that, it's made the code more stable however there is an annoying problem with clean-up, there's no onShutDown event for Android's GLSurfaceView class so I had to make my own version that adds the shutdown command onto the GL thread, but by the time it's called the context is already trashed so GPUs spit out a warning for attempting GL calls on an invalid context, luckily everything works fine and it's just GL wind-down calls that are being attempted, using that moment to destroy my rendering engine works fine (And is fast).
Being able to rotate and close the app without it crashing feels great.
coyotecraft
Sponsor
Hurdles of working with a second spriter. Communication.
Glitchfinder
Staff
I was bored and made a video of that last Minecraft terrain generator's end result.
http://www.youtube.com/watch?v=mCeRL8zHKSM
I maintain that C418 is a skilled creator of non-generic elevator music.
http://www.youtube.com/watch?v=mCeRL8zHKSM
I maintain that C418 is a skilled creator of non-generic elevator music.
Wrestling with Android still.
This 1 day task will now consume 3 days of work.
I need an efficient way to get AndroidView into my material renderer, after day 1's failures I realised it's best to treat the Views as Materials and keep them as much in the C++ renderer as possible.
Day 2 I try to implement that. Of course, Android Views can't be spawned on the GL Rendering thread.
Day 3 will be spent implementing a callback system so Materials are created, but aren't used until the view is created, which is requested by the GL thread to the UI thread, which will run a callback to the C++ code that will run any pending calls that were intended for the View and then.
HOLY FUCK, just as I was typing that, I got a Facebook notification about someone addressing my Android problems and, Android being the dumb platform it is, started an instance of a media server and started playing a random song from my phone.
The song it picked;
http://www.youtube.com/watch?v=Si3C1EtGo4c
No joke, creeped me out big time...Such a broken OS.
This 1 day task will now consume 3 days of work.
I need an efficient way to get AndroidView into my material renderer, after day 1's failures I realised it's best to treat the Views as Materials and keep them as much in the C++ renderer as possible.
Day 2 I try to implement that. Of course, Android Views can't be spawned on the GL Rendering thread.
Day 3 will be spent implementing a callback system so Materials are created, but aren't used until the view is created, which is requested by the GL thread to the UI thread, which will run a callback to the C++ code that will run any pending calls that were intended for the View and then.
HOLY FUCK, just as I was typing that, I got a Facebook notification about someone addressing my Android problems and, Android being the dumb platform it is, started an instance of a media server and started playing a random song from my phone.
The song it picked;
http://www.youtube.com/watch?v=Si3C1EtGo4c
No joke, creeped me out big time...Such a broken OS.
Doing some basic world building for Exodus - Characters, Locations, World Lore - When I get bored with that I open up photoshop and work on some parallax mapping. Hopefully I'll get some screens ready in the near future. The game is planned to be kind of massive in scope though --- so I'm hoping I'm not biting off a little more than I can chew with a massive game world.
