Dinosaurs on a Spaceship

edited April 2013 in Projects - Tools
Hi there! It's been a long time since I've posted here, I'm sorry for the late post but I've been very busy with the game.
As I promised, though, I'm posting about it now since we released a trailer.



Let me know what you think about it :)

Comments

  • edited April 2013
    Hi subr3v,

    Nice work! :)

    A quick question, the scrolling at the end of the video isn't really smooth, is that something that happens in game or just an artifact of the video capture?

    You might want to try the branch named "two_phases_render" that I recently created on the hg repository, it contains a couple of changes:
    - the render commands are pushed at the beginning of a frame (ie. with a frame of delay), trying to get the GPU to work as much as possible in parallel with the CPU
    - in fullscreen + vsync, there's a synchronization point at the end of a frame (after the swap buffer command has been pushed)

    Those should give the following results (fullscreen + vsync only): no more micro-stutter due to driver-controlled frame skipping and no more input lag (due to driver-controlled frame queuing).

    Sorry for the digression and congrats again for the teaser! :)
  • edited April 2013
    Thanks for everything :)

    The scrolling wasn't really smooth because the video was recorded on a mac with a virtual machine for windows (yeah, not the best idea.. I know, XD) but everything is fine in game.

    I'm not sure about trying that branch, because I'm also using openCL for the new lighting system (it's not shown in the teaser though) and that alone should keep the GPU busy :P
    When I'll have some spare time, I'll try it though.. who knows what might happen.

    Totally unrelated: do you have any experience with openCL? Do you think that shipping a game with that technology is ok in 2013? :P
  • edited April 2013
    I've only played a bit with OpenCL (and compute shaders) but never had a real use for it.
    Also I'm not a professional graphics programmer (my work over the last decade was mainly on game AI), so I'm probably not the best person to ask for that. :)

    My concern is that it's already easy to write un-optimized fragment shaders, even given the simple workflow (cf. a recent presentation by Humus to which I attended during GDC: http://www.humus.name/Articles/Persson_LowLevelThinking.pdf), so I have the feeling it's probably much worse with even "higher level" shaders. :)

    If you try the branch version, please let me know, I consider merging it back to trunk soon-ly if no one find any issues with it (the forced GPU/CPU sync will then be optional, which isn't the case in the branch).
  • edited April 2013
    Thanks for the presentation :P It was interesting to read!
    Optimization is always a problem with GPU code, but I think I somehow managed to reach a decent level (hopefully) :D
    As for the branch version, I'll let you know as soon as I try it.
  • edited April 2013
    Thanks! :)

    Out of curiosity, for what do you use OpenCL in DoaS?
  • edited April 2013
    I used openCL to implement a lighting system that allows multiple light sources with normal mapping and dynamic shadows.
    It's exactly the same thing as the shading part of a raytracing algorithm ( light attenuation, normal calculation, shadow ray)
  • edited May 2013
    Small update:
    I'm using the two-phase branch version and I didn't notice any kind of problem until now (it's been some days already)
  • edited May 2013
    Thanks for the update!

    I actually merged it back to default a day ago.
    Hopefully nothing will break badly. :)

    I almost did the MRT support last night then realized I was too tired to focus and played Monaco instead. I'm weak. ^^
  • edited May 2013
    Haha, sounds like I can't manage to keep my code updated with the last version of orx at this pace! :D

    MRT support would be sweet for being cross-plaftorm again! (even though I'll probably work on full cross-platform during the last months of development, so I don't have to worry about it now).
  • edited May 2013
    Hehe, I should probably look into setting up nightly builds too for those who don't like to sync the repo. :)

    As for MRT, I'm fairly sure it should be ready before you have to manually support it for other platforms as well.
    I'm not sure what your target platforms are, but, as a precision, just in case, MRT won't be available for the OpenGL ES ones (iOS/Android), unless new devices with OpenGL ES 3.0 are released before your game. ;)
  • edited May 2013
    My target platforms are Win and Mac, I'll probably attempt a porting of the game for PS Vita with the native SDK when I'll have the chance to work with it.
    Do you think there will be any problems with the PS vita porting?
  • edited May 2013
    Win & Mac should work out of the box, from an orx-perspective. Same for Linux if you decide to release it for that platform.

    For PS Vita, however, it won't be as straightforward: you'll have to write you own set of plugins to support that platform.

    95% of orx core should be platform-independent, and it should be fine for Vita from what I can remember (I worked on Vita games for 2 years, however on the AI/Gameplay side, not the engine).
    The remaining 5% might concern memory pre-allocation and some various Sony system inits, nothing really scary.

    Regarding the plugins, you can usually adapt an existing one and the whole porting can be done in a few days.

    The Physics and Render plugins should not need any modification.
    You'll however need to compile binaries for orx custom version of Box2D for the Physics plugin.

    Also, you won't likely need a keyboard plugin and can then use the "dummy" one that comes with orx (it's just an empty shell).

    That leaves you with the display, sound, joystick and mouse plugins. Joystick and Mouse are fairly short and easy to port (they only have a few functions in their API).
    If you want to support multi-touches, you'll also have to send the corresponding orxSYSTEM events when appropriate.

    The sound one could either be very easy (if Vita support some version of OpenAL), or a bit harder if you need to go via FMod (as we used to do where I worked) or Sony's native library.

    The display one is probably the biggest chunk of work as Vita doesn't support OpenGL. You'll have to port the code to support gxm, I believe, which might take a couple of days or maybe a week.

    The hardest part of converting your game will probably be TRC conformance, making sure you react well to all Sony systems (such as NEAR) and fulfill all their requirements.

    But that isn't really related to orx per se. :)

    Anyway, when that happens and if you need some help, lemme me know if you want to do some sort of contracted support. ;)
  • edited May 2013
    Thanks for the general overview of the porting process :)
    It's reassuring to know that you already worked on PS Vita hardware and I won't hesitate to ask you more (contracted supports) if the need arises.

    Thanks again, I'll keep the post updated as the development progresses.
  • edited May 2013
    My pleasure.
    As for current/next gen console platforms, most, if not all, of them are covered by NDAs, which means I can't provide any public support with orx and all has to go through contracts, which is a pain in the ass.

    I hope the steambox won't have this issue. :)

    Looking forward to hearing more about DoaS updates in the future!
Sign In or Register to comment.