Elysian Shadows

.....and what should be in the engine??


Hi! I have some questions about libgyro (or similar api type things).

I've been writing a 2d (mainly) engine for some time, and wanted it to be potentially multiplatform from the start. I chose to do it in c++, and using opengl, as these seemed sensible at the time. I'd only been building for windows for years, but just decided to try on dreamcast using sdl/opengl, as i just found out about the toolchain installer - nice work to the people who made that! Anyway, I had a number of headaches and discoveries - some asserts won't compile for some reason - not that i'm using them on dc at the min, and neither will passing a value to base class constructor from a derived class. Also drawing after binding texture 0 (to unbind) causes unknown opcode, and glOrtho doesn't work as intended, but i'm sure you all know this - anyway, the main discovery was that using Opengl in this way is really not fast at all on dreamcast (will try kgl next i think...).

That's when I found these forums! (remembered seeing the kickstarter on kotaku and thought it looked good, but didn't realise it was on dreamcast!). Then i watched some of the old youtube dev videos, and saw the stuff on Libgyro - it isn't public (yet?) is it? couldn't find it so i guess not..


Am i right in thinking that it is a header(s) that is the same for all platforms, with different c/cpp/o/lib/a/whatever files per platform? (are you using c/c++ on Android?)

does it use opengl (or direct x) on pc? (and does it use shaders? - EDIT - of course it does - you've just had the problem with the flipped normal maps/tangents/etc.. so how are you gonna emulate this look on dreamcast??)

does it use kos/ pvr.h and such things for actual powervr assembly on dc?

what exactly is in the header file(s)? and what data is stored within it? like, is all of the vertex data and matrices and stuff stored within that class(es)? what do you actually call from the game engine to load a texture and display a portion of it in a quad at a certain scale/rotation?

not necessarily libgyro specific - i just want to find out what is the best way to do such things and make it easy to port!

Anyway, good luck with the masters to Falco - would like to read that when it's done!and good luck finishing the game! hope you don't kill yourselves crunching!

Hey Tommy, welcome to the forums!

I can only answer a couple of your questions. Yes, ES uses OpenGL on PC, and yes there are shaders. There are definitely some advanced rendering techniques which are not possible on the Dreamcast 1:1 with PC. Rest assured, one of Falco's main drives from the very start has been getting the game to look as good, if not better in certain aspects, on the Dreamcast as it does on PC.

Likewise, the Dreamcast supports a few things that aren't available on the PC; the VMU for one. There are rumors of plans to use the VMU to compliment the play experience on Dreamcast, something strictly PC gamers will miss out on. Obviously it won't be a core game mechanic, but rather a fun little bonus for the hardcore DC fans. Hopefully, each console will provide a unique experience in its own way.

Hi again!

Yeah, I liked being able to see my health whenever in code veronica, but it was a bit too hard to see in the middle of a boss fight for it to be much use..

Maybe something like that item in ocarina of time, where if you have a rumble pack, it rumbles when you get near a secret - you don't need it, but it's helpful if you have it - some sort of item in Elysian Shadows (or other Dreamcast RPG) that helps you to locate hidden treasure using the vmu screen. Maybe that would be a cool use of it? It sounds cool to me, anyway.. or an item that helps display the % chance that an enemy is gonna do its rare drop?

Anyway...

I fixed my compile problems if anyone is interested.. adding kos.h as well as assert.h fixed the assert ones (so shouldn't kos.h, or some part of it be included in assert.h?). maybe my version of kos is out of date...

as for the calling base class constructor - the base class was a template, and i'd left out the <type> bit after the baseclass in :-

derivedclass (sometype value) :baseclass (value)
which is now
derivedclass (sometype value) :baseclass<thetype> (value)

my pc compiler doesn't mind the first one...