Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

223 Neutral

About EnemyBoss

  • Rank
  1. EnemyBoss

    Do you remember this game?

    Last week I competed in Vortex '09 in Toronto. The contest was to deliver the best pitch for a game idea or prototype. I didn't give myself time to come up with a solid game pitch, so I thought of jumping on the classic-remake bandwagon and remake the IREM NES classic "Metal Storm". There's alot of retro remakes free on the web but I didn't see one for this game, so I thought it might be an interesting project to pitch. METALSTORM2.PDF. When I pitched the idea, the Judges only asked if I tried to obtain a license for the trademark. Maybe they were hoping for a yes? Let me know what you think. Vortex was fun and I learned alot. I think I'll attend the next IGDA and Hand Eye meetings in Toronto from now on, even if I'm not working on anything worthwhile these days.
  2. EnemyBoss

    EnemyBoss LE

    I finally got to put a temp site on After understanding the limitations of the web space, and FTP not appearing to work, I decided on a plain html site with the old work I did 3 years ago. I hope that when I get the creative juices flowing and some income, the site will relaunch with some new games.
  3. EnemyBoss

    My first synth.

    At time I should be cut spending, I decided to invest in a synth/midi keyboard. I'm pretty competent making my graphics in Gimp and Blender using my Graphire4 tablet. When it comes to sounds however, I just find existing works. I don't know music theory or sound engineering, but I wanted something to toy with. A while back, my brother got Korg DS-10 for his DS. I played it with for hours, and I realized that making and controlling rhythmic noises is fun (and sometimes very funny!) Instead of buying my own copy of Korg DS-10, I investigated into full-fledged synthesizers. My investigation told me that software sequencing and synthesis is the way to go these days, but software still benefits to have a MIDI keyboard controller. I decided to go for an affordable mini synth keyboard, which could be used both as a soft-synth controller and a musical toy. Except for a toy harmonica, my household has no musical instruments. It was a tough decision between a MicroKorg and the Xio. Both are small, battery operable synthesizers, which can be used to model wonderful stereo sounds. Both could also be used as good MIDI compatible controllers for software. The MicroKorg seemed to have a lot of what the old school synths had to offer. I really fell in love with the Korg brand because of the DS title. The MicroKorg also looked really fun to use, especially with the voice changing Vocoder. Tom Lee Music had it for only $80 CAD more than the Xio during the boxing week. The Xio however seemed to fit my needs better: Its USB interface can be used to power the Xio and use it as a low-latency audio interface, as well as a MIDI interface. Had I gone with the MicroKorg, I would have had to buy a MIDI-USB cable and maybe a new soundcard, if I found the onboard sound on my to PC to have poor key-to-sound latency. I purchased the Xio online from Tom Lee Music, and I received it yesterday. I'm having plenty of fun with the Xio's synthesizer, the presets are all very good and varying the sound is easy with the 2D joystick. Next, I'll go through the video tutorials and learn more about the basics.
  4. EnemyBoss

    Video Games Live - more than just a concert

    I got to see VGL when they did a free show in last summer in Toronto. Highly recommended!
  5. EnemyBoss

    Tightening Up

    Well I canceled my hosting service, and so my site is down. Money is getting tight I'm just cutting down on expenses where I can. I'm still looking for a job. My personal site now just points to my linked-in profile, which serves the same purpose actually. I might just keep it that way. And as for, I'm hosting it right here on Why not use the space while I still own it? My site was PHP based, so I'm going to need time to redo a smaller DHTML version of it. I've been wanting to redo the site anyways. I've been doing a lot of reading on game programming. I've even started re-reading Andre LaMothes' The Black Art of 3D programming. I don't know why I keep coming back to this book, especially when I have yet to read his more current book, Tricks of the 3D Game Programming Gurus. And I'm hoping I'll soon move forward with my game project soon. Its not bad having this much available time. Its almost worth the money.
  6. EnemyBoss

    Well that didn't last long...

    Blame it on the economy or whatever, but I'm unemployed again. I didn't survive the cuts past my probationary period. My experience at TransGaming was still very postive though. So its back to my favorite vaporware title until I find the next job. I might also consider doing freelance work, but I don't trust a lot of the work thats posted on places like rentacoder. Anyone know who's hiring in the Greater Toronto Area?
  7. EnemyBoss

    New Job.

  8. EnemyBoss

    New Job.

    I start my new job at Transgaming on Monday. I didn't get to finish a game like I set out to do when I left my last job, but I got at least some time to it. Hopefully, I won't be to busy after hours to work on my new game. I've been stuck trying to build my own simple sprite engine. For some reason, I am determined to code this in plain C only. This results however in engines that are not very flexible and I end up re-writing. I am also trying to achieve simplicity in design(which is also very difficult). So far my sprite management looks like this: /* Handlers initialize a sprite's data on the 1st call, then updates logic */ typedef void ( *SPRITEHANDLER )( struct sprite_t *sprite ) struct sprite_t { float px, py, dx, dy; BITMAP *sprite; void *extra; SPRITEHANDLER update; struct sprite_t *next; }; /* Creates Sprite Object and add to sprite list */ struct sprite_t *spawn_sprite( SPRITEHANDLER sprite_handler, int x, int y ); /* Removes sprite from the list and de-allocates it */ void kill_sprite( struct sprite_t *sprite ); /* Invokes the sprite handlers to update logic (at a low internal FPS ) */ void update_sprites( ); /* Moves all sprites one step based on its velocity, invoked once per frame */ void move_sprite( ); /* Draws all sprites to bitmap object, invoked once per frame */ void draw_sprites( BITMAP *video_surface ); The "sprite handler" functions as a sort of class for each sprite. I would have a handler function for each type of sprite. I'm afraid however that this design may be too restrictive. I haven't considered how I would display multi-sprite objects, or how they would communicate with each other. I really need to think the design through. I just need more time.
  9. EnemyBoss

    The Perfect Gameloop?

    If anything reminds me how far I have to go as a game developer is my recent considerations for the game loop. I want to have absolutely smooth scrolling and moving sprites, without resorting to OpenGL or Direct3D. My initial testing of both SDL and Allegro page flipping modes indicate this can be done, depending on how I implement the game loop. I initially went with the timed game loop, where I update the movement in the game based on the measured time between frames. I thought that this would make sprite movement as easy as following a physics text book, and run smooth at any refresh rate. This was the technique used in David Brackeen's Java game programming book. while ( game_is_running ) { elapsed_time = get_time() - last_time; last_time += elapsed_time; get_user_input() update_game( elapsed_time ) render_game( screen ) wait_for_retrace(); } What I got was intermittent "blibs" between smooth movements. Apparently, even the underlying performance timers for windows are not 100% reliable. At first I blamed the page-flipping implementation in SDL, because an Allegro demo showed smoother animation in page flipping mode. I almost abandoned SDL until I realized that the SDL.DLL pre-built for Windows will not use DirectX unless the %SDL_VideoDriver% variable wasn't set to "directx". I figured this out when I noticed that SDL_VideoInfo()->hw_available returned false. After modifying the gameloop to sync with the refresh rate made the SDL version move just as smooth in double buffered mode as with Allegro in page-flipping mode, as long as I both updated and rendered the game at retrace. I've read that using a time-interval like above would cause physics calculations to compound on rounding errors and otherwise break gameplay. The elapsed_time could be clamped to a reasonable max/min before being passed to the update function. In any case, I could not get the smooth uninterrupted movement that I wanted. I still didn't want the game-speed to be dependent on the frame-rate. The next thing I tried was fixing the update rate at 60Hz, while calling the rendering function at retrace, or as soon as possible. #define FRAME_INTERVAL 1000/60 frame_time = game_time(); while ( game_is_running ) { get_user_input(); /* Update only at 60Hz. Skip if we're running under */ while( game_time() > frame_time ) { update_game(); /* Update one tick */ frame_time += FRAME_INTERVAL; } render_game( screen ); } I could have also put a condition to allow the loop to skip a few updates if the loop is running slow (under 60 updates per second), but I wanted the game to go into slow-mo and not skip a frame. This wasn't good enough because while it looked great on a display that could support 60Hz, the 50Hz LCD on my thinkpad (and primary development machine) made it look all jumpy. Thats because the game was updating faster than my LCD. If I slowed the updates to 50Hz, it looked fine on my laptop, but it appeard "laggy" on the CRT monitor because it was refreshing faster than the updates. Actually, I'm exagerting the lag and jumpyness a bit but I didn't want to use this loop. BTW: I forget where I actually learned about these game loops, If I remember the link I'll post it. The last method I implemented was rendering partial frames or "tweening". This is achieved by locking the internal frame rate (updates) at 50Hz, measuring the time between rendered frames and passing it to the render function as a fraction out ofa 50Hz frame period. The 50Hz was chosen so that it work well under a 50Hz monitors (LCD or PAL TV). #define FRAME_INTERVAL 1000/50 frame_time = game_time(); while ( game_is_running ) { get_user_input(); /* Update only at 60Hz. Skip if we're running under */ while( game_time() > frame_time ) { update_game(); /* Update one tick */ frame_time += FRAME_INTERVAL; } current_frame_time = ((game_time() + FRAME_INTERVAL) - frame_time); tweening = current_frame_time / FRAME_INTERVAL; render_game( screen, tweening ); } Then when it comes time to render my sprite, I predict where the sprite will be based on its current velocity (dx,dy) and draw to that location on the screnn: void render_sprite( sprite, screen, tweening ) { x = sprite->x + sprite->dx * tweening; y = sprite->y + sprite->dy * tweening; blit( sprite->frames[ sprite->frame ], screen, x, y, sprite->w, sprite->h ); } This approach is very good. Even if I set the the internal frame rate to say 30Hz or even 24Hz (feature movie display rate) movement looks quite smooth even on both my 60Hz CRT or 50Hz LCD and at the same speed. Again, the loop will not throw out frames if running behind and will opt to slow-mo. For my requirements, I need precise collision detection because the player will be dodging many bullets as well as enemies. So I may need to run collision detection frequently as once per rendered frame. So despite my reservations of locking the frame rate, I'm going with the simple text-book approach of waiting for the next frame period at the end of the loop. I'll separate the update() function into compute_AI() and animate(), so that I can do the AI at a lower frame-rate (maybe @20Hz?) , then animate and render the game at 60Hz. This way I can rely on the refresh rate for smooth scrolling and animation, while relying on the system clock for logic. This also means that my game would slow by 16% on my 50Hz LCD, but it will still look smooth. I think I can live with that. I might then go with using Allegro, since it lets me request and query the display's refresh rate and supports both page and triple buffering. None of these features as far as I know are supported in SDL 1.2 (perhaps purposely so). I'm open to comments, because I know locking the game speed to a 60Hz display refresh rate isn't ideal for most players.
  10. EnemyBoss

    Plan B

    I tried both your Orc and Arc demo. Both are great, but the telekinesis power in the Orc demo shows off the physics simulation. I imagine this is how telekinesis must have worked in Psi Ops. Did you only use Bullet to accomplish this? I think your attempt at making a world editor is worthwhile, especially if the game could switch between play and edit modes on the fly. I'm still doing things in 2D, and your "prototyping" sandbox library is similar to my approach to my next game's internal framework. Do you find this approach to a game application inflexible in some way that it is only good for prototyping? Thanks.
  11. EnemyBoss

    Suprise! Anyone can Sketch

    I keep scrap paper on my recycled main-board clip-board, which i use to make notes. I was writing out my thoughts on the design of the new game, and for some reason started doodling 3D boxes in the bottom right of the page. The shapes began to look like it needed details and then something magically appeared. I think I've discovered how to sketch. I was thinking of a jumping tank with dual rockets/gun turrents. What you see here is the result much erasing and re-penciling. I then colored it in GIMP (much undo/redo). Its not much too look at , but it is my first real pencil sketch ever, and I'm damned proud of it! Because the game is going to be rendered from the side view, I want to to employ elements of gravity into the game. So there will be arching missles, bombs and jumping rocket-pack mechs, etc. I was thinking this tank could tag the player a bit and make a surprise leap-attack. This sprite design probably took me much longer to do on paper, than say these using Blender and GIMP, but it was a lot of fun and I can do it anywhere. I might do a few more paper sketches for fun.
  12. EnemyBoss

    Why the GPL bugs me

    I've been looking at Allegro, and it has a more permissive "Giftware" license. You can easily make a single statically compiled exe and you don't need release the sources per the LGPL. In fact, I think Allegro exposes more of the features in Direct Draw than SDL, such as creating video-pages, an actual wait for vsync function and requesting of refresh-rates. The demo also hints triple-buffering support, which isn't in SDL yet (Double buffering only). It would be great if it worked like this for Mac and Linux. I use SDL, but I'm giving Allegro a try for my next project. While I think Allegro isn't a model of best software practices you would want in a game toolkit, it has plenty of documentation and support. It maybe something worth looking into if you're just doing things in 2D.
  13. EnemyBoss

    X years in Development

    I actually I know SDL better than Allegro. SDL was my original choice of platform for the previous project. I may abandon the notion of a DOS port (for the sake of the old project) and wouldn't mind starting over again with SDL.
  14. EnemyBoss

    X years in Development

    About two weeks ago I found some old files and code on a disk inside my copy of the "Black Art of 3D Game Programming". These were from my first attempt to get into game programming in 1998 when I bought this book. This book IMO is the best book on game programming available at the time. I remembered making my first VGA program based on it. But I didn't remember until now is that I tried to make a vertical scrolling shootem'up - just like that "Gunhacker" project I previously attempted over a year ago. I used DJGPP and Allegro back then, and graphics were going to be pre-rendered in POV-Ray and Terragen. I guess University got in the way and then I completely forgot about it. So last week I decided to make a third attempt at an R-Type clone, using the work from both projects. All the tools I used back then are stillarround, and Allegro is even still in development. So does anyone want a new DOS game 10 years in the making? Seriously though, my plan is to and port the work to MinGW and the Windows version of Allegro, using the newer assets I made for the Gunhacker project. I can then (maybe)make a DOS port the project and put a close on both these unfinished projects. Question: How good is Mac/Linux support under Allegro? From what I've read, Mac and Linux support is new and not as optimized as under Window. I might consider using SDL (I really don't care about targetting DOS). I think its important because Mac and Linux could use more games.
  15. EnemyBoss

    High Concepts

    Absolutely. I want my next game to use 2D sprites and with one or more scrolling background layers. In fact I've already picked a project to do, I'm just in the process of catching up with the log entries.
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!