Dreamcast-Talk.com

111 wrote:

kazade wrote: I'd be interested to know more about the approach you took for collision detection and response. Did you use any pre-existing libraries or is this all home-grown?

I use kazmath lib. It does not have absolutely everything you'll need (I adopted some things like finding closest point on line, ray-sphere intersection etc. myself), but from what I've seen it's probably the most complete 3d math lib for C (not C++).
Generally speaking, it's all done using ray casts.

Hah! That's my library! Glad you've found it useful! Feel free to send me pull requests Github if you feel there is anything missing

111 wrote:

If you have any tips to share on developing for the DC I'd appreciate it

well, I'm still new to it and don't really know that much. Are you working on something as well or just considering at the moment? Do you have any experience with 3d or programming in general?

And if you have any KOS-related questions, than dcemulation forums is probably your best bet.

I'm considering porting my game engine to the DC, just wondered if you had any advice on the development process.

kazade wrote: Hah! That's my library!

ah... ok, cool (I probably mistook you for someone else with similar nickname, sorry)
Quite a pleasant surprise I must say!

Glad you've found it useful! Feel free to send me pull requests Github if you feel there is anything missing

well thanks. It would probably be nice to have more intersection routines (ray-cylinder, sphere-edge etc), frustum checks and so on, but would not it be too much to ask for?

Replacing square roots with faster ones might be a good idea though (at least for vector normalization). I use the first method from this great article: http://www.codeproject.com/Articles/699 ... on-Precisi

111 wrote: I'm considering porting my game engine to the DC, just wondered if you had any advice on the development process.

I see. Well then, some quick kgl notes:
1. Do not use immediate mode. I know this one is kinda obvious, but aside from this, you will also get near_z clipping issues.

2. Do not use lighting. It is slow and buggy (no disrespect to PH3NOM, it's just too much for a 200mhz cpu). But considering T&L is done entirely in software anyway, this is not really a significant lose.

3. You will definitely want to use compressed pvr textures. Be aware though, that there is minor issue with glTextureLoadPVR(). http://dcemulation.org/phpBB/viewtopic. ... 9&t=104054

4. If you bind at least one texture, you will be unable to disable texturing altogether (i.e. glDisable (GL_TEXTURE_2D) will not work). My workaround for this is applying white texture.

5. In case you was not aware, there is hardware support for order independent transparency. All you have to do is just enable\disable depth test and blending when needed and render whatever you want without worrying about visibility checks etc.

But you might as well just use pvr api instead, if you feel like it.

And you probably should not use c++ for various reasons.

PM me if you need more info about something from my "engine".

111 wrote:

kazade wrote: I'm considering porting my game engine to the DC, just wondered if you had any advice on the development process.

I see. Well then, some quick kgl notes:
1. Do not use immediate mode. I know this one is kinda obvious, but aside from this, you will also get near_z clipping issues.

2. Do not use lighting. It is slow and buggy (no disrespect to PH3NOM, it's just too much for a 200mhz cpu). But considering T&L is done entirely in software anyway, this is not really a significant lose.

3. You will definitely want to use compressed pvr textures. Be aware though, that there is minor issue with glTextureLoadPVR(). http://dcemulation.org/phpBB/viewtopic. ... 9&t=104054

4. If you bind at least one texture, you will be unable to disable texturing altogether (i.e. glDisable (GL_TEXTURE_2D) will not work). My workaround for this is applying white texture.

5. In case you was not aware, there is hardware support for order independent transparency. All you have to do is just enable\disable depth test and blending when needed and render whatever you want without worrying about visibility checks etc.

OK, thanks that's really useful. I might take a look at fixing a couple of those issues when/if I hit them. BTW, you probably want glBindTexture(GL_TEXTURE_2D, 0); - glDisable(GL_TEXTURE_2D) isn't valid

111 wrote: And you probably should not use c++ for various reasons.

Yeeeeaaaahh... unfortunately my game engine is like 60000 lines of modern C++ code - fun times!

This is really cool, I like the funny way the character walks with his arms swinging... and when he jumps he sorta' floats... I think this should take place on a space station with "slightly off" gravity, it's awesome! Can't wait to play the released version, nice work!

Padre wrote: and when he jumps he sorta' floats... I think this should take place on a space station with "slightly off" gravity

... you are probably getting it all wrong though, it is kinda slow because framerate was not 60fps (and timers, for now, are tied exactly to that without delta-time compensation in case there is a slowdown). Jumping animation (and others) needs work as well.

it's awesome! Can't wait to play the released version, nice work!

thanks!
-------------------------------

update:
- testing another weapon





also, over the shoulder view will probably be removed because of reasons.

111 wrote: ... you are probably getting it all wrong though, it is kinda slow because framerate was not 60fps (and timers, for now, are tied exactly to that without delta-time compensation in case there is a slowdown). Jumping animation (and others) needs work as well.

I don't know if you'll find this helpful? https://github.com/Kazade/Kaztimer/

It might need tweaking for the DC, but it uses an accumulator to detach physics updates from framerate.

kazade wrote: I don't know if you'll find this helpful? https://github.com/Kazade/Kaztimer/

not really, sorry. Don't get me wrong, it is definitely good, but this is not exactly what I need (nor do I use physics engine anyway).
And I am definitely not a fan of so called "FPS independent game loop". Because I don't want to force CPU usage to 100% (in case of one thread and single core cpu) just to get some extra frames nobody would notice anyway. On the other hand, "dirty" solutions like Sleep(1000/FPS) do work well (for me at least) and CPU usage is barely above 5-10% (unless desired framerate is not met).
But what do I know, I'm just a beginner...

And I'm still surprised how much of your stuff is terribly overlooked by me.

It might need tweaking for the DC, but it uses an accumulator to detach physics updates from framerate.

well that's for sure, considering things like QueryPerformanceFrequency().
Also, it is possible to get GPU statistics (framerate included) using KOS, but I have not tried that yet.

By the way, do you read PMs? I sent one several days ago...
-----------------------------


PS: just wondering, why am I "rebel"(lol) now instead of "shadow"? Guess it has something to do with the first post edits, but whatever.

111 wrote:

kazade wrote: I don't know if you'll find this helpful? https://github.com/Kazade/Kaztimer/

not really, sorry. Don't get me wrong, it is definitely good, but this is not exactly what I need (nor do I use physics engine anyway).
And I am definitely not a fan of so called "FPS independent game loop". Because I don't want to force CPU usage to 100% (in case of one thread and single core cpu) just to get some extra frames nobody would notice anyway.

Yeah, you're probably right. For physics engine solvers it's important that updates happen with a fixed step or you get errors. But in your use-case just limiting the framerate is probably the better solution.

111 wrote:

kazade wrote: It might need tweaking for the DC, but it uses an accumulator to detach physics updates from framerate.

well that's for sure, considering things like QueryPerformanceFrequency().

That's only on Windows, on anything else it uses clock_gettime - I was hoping KOS had an implementation of that

111 wrote: By the way, do you read PMs? I sent one several days ago...

Yeah sorry about that, just replied

Kazade will this game get a physical release? If so where could I buy it and how much would it cost?

HCRAYERT504 wrote:Kazade will this game get a physical release?

...not sure why are you asking Kazade about this, but anyway, the answer is "maybe if it's finished". But that's a big "if".

Thanks for your interest, it's really nice to know there are people willing to support the project with money (as for price, I guess 10-15$ would be fair enough)