RMQ Engine after compile crash

[toneddu2000]

Hy guys, I heard that Spike added CSQC to RMQ Engine (which, if I understood correctly, is forked from QuakeSpasm, which I love btw) and I tried compiling. After some problems with SDL, I understood it needs SDL-1.2.15 instead of SDL2 and I compiled SDL2_net-2.0.0 (which is required) from SDL-1.2.15 instead of SDL2 on MVSC++2013. I started RMQEngine.exe but if I run the demo, no problem but if I issue the command map whatever.map it crashes with every map. Anyone had same issue? I found the source here

Thanks in advance. I'd really like to use this fork because QuakeSpasm + EXT_CSQC is pure awesome!

[Spike]

don't get your hopes up with rmq+csqc. it should be usable for huds, but nothing more. you'll also need to ensure you have the 'right' system defs set up for it, which don't match either the fte or dp ones (as a wip implementation, it was a case of doing whatever was simplest to bootstrap the implementation, with proper support later, except that its no longer maintained).

[toneddu2000]

well, I didn't rely too much on this fork. Once I'll have managed how to open NetRadiant maps on FTE (if anyone had same problems it would be appreciated an input) I'll stick with it. It's was just the curiosity about how to implement EXT_CSQC on quakespasm, nothing more.
Nevermind, I noticed that Debug profile works, Release does not. Well... I'll use Debug one!
Thanks Spike for the clarification, I heard that the csqc implementation was just a stub but I wanted to dig the whole thing up!

[r00k]

I've tried to compile the RMQ engine, too. Older versions will compile, newest source i could find compiled, but some surfaces would not render, like missing portions of a wall/floor..

[toneddu2000]

Can you please tell which portions of walls/floors are not rendered? In which map? So I'll compare it with my version

[r00k]

this version is the version where MH added a bunch of shader support. I wanted to compile it so i could compare the speed vs the dec 2010 version, which does compile just fine.

[toneddu2000]

mine.

I download the source here. There's another repository?

[goldenboy]

It's a WIP engine from a dead project. It was never intended as a general use Quake engine and never officially declared stable. It doesn't support SDL 2 - you'll need libSDL and sdl-mixer version 1.xx to compile. Linux version compiles fine for me, btw.

The latest public version is in the RMQ SVN repository which is still online - http://svn.icculus.org/remakequake/engine/

No guarantess if it will compile.

Yep, it was forked from Quakespasm but it uses a new protocol (999) by default and I believe MH changed quite a few things.

[toneddu2000]

Thanks gb for the clarification, appreciated.
Spike, could youd write (if you have some spare time, of course) a mini doc about how to add EXT_CSQC on QuakeSpasm(which functions to edit, which functions to add, which defines to create, etc.)?

I think it would be a really interesting lecture.
I'll investigate this addition on my own, anyway

PS: I found this document you wrote, and it's REALLY interesting

PPS: I heard about Moodles, sorry about that

[Spike]

Spike, could youd write (if you have some spare time, of course) a mini doc about how to add EXT_CSQC on QuakeSpasm(which functions to edit, which functions to add, which defines to create, etc.)?

The issue here is that the answer is 'pretty much everything'.
Its not something that you can trivially bolt on the side, although hud-only support might be possible that way. If you want a complete implementation then expect to get your hands dirty - VERY dirty. As well as the code.
You can probably google for csqcwinquake, which was a winquake/glquake sourcebase with csqc support. It was meant to be a sample implementation built upon vanilla which would be easier to create diffs for other engines, and yes, a 'bolt on the side' attempt... It should give you an idea of the amount of work required. I don't remember how complete it is now, nor how robust it actually is, but I'm certain that it lacks lots of convienient stuff, sadly.

[toneddu2000]

The issue here is that the answer is 'pretty much everything'.
Its not something that you can trivially bolt on the side, although hud-only support might be possible that way. If you want a complete implementation then expect to get your hands dirty - VERY dirty. As well as the code.

I see..

You can probably google for csqcwinquake, which was a winquake/glquake sourcebase with csqc support. It was meant to be a sample implementation built upon vanilla which would be easier to create diffs for other engines, and yes, a 'bolt on the side' attempt... It should give you an idea of the amount of work required. I don't remember how complete it is now, nor how robust it actually is, but I'm certain that it lacks lots of convienient stuff, sadly.

But who's the author of csqcwinquake? I mean, is a reliable csqc port?

Last "spiky" question: which engine do you think is better "csqc oriented": dp or fte? I saw A LOT of differences in methods parameters and effectiveness(I concentrated most on skeletal animation part) between your engine and LordHavoc's one. Are they both considerable reliable to make a game from scratch that builds its roots strongly on csqc (even because, if you discard these 2 engines I don't know any other engine with csqc builtin! ) ?

[Spike]

You can blame me for csqcwinquake. its old and thus lacks all the mod-cons. I'm sure it also omits parts of the spec-at-the-time (for instance, the software rendered version ignores half the drawpic arguments). One thing it definitely lacks is skeletal models and thus the skeletal animation extension builtins too.

both engines have their strengths and weaknesses.
I would say that fte is more versatile with its csqc (of course I would!). However, with extra versatility comes extra reconfiguration/code, thus both engines have their advantages.
Start off making your mod work on both (testing with each on alternate days or something) and at some point drop the one that annoys you the most?

[toneddu2000]

You can blame me for csqcwinquake. its old and thus lacks all the mod-cons. I'm sure it also omits parts of the spec-at-the-time (for instance, the software rendered version ignores half the drawpic arguments). One thing it definitely lacks is skeletal models and thus the skeletal animation extension builtins too.

I see.. Well I'll take a look at it anyway. At least to understand the main areas that need to extend to CSQC.

I would say that fte is more versatile with its csqc (of course I would!). However, with extra versatility comes extra reconfiguration/code, thus both engines have their advantages.

Well, I've seen by myself one of fte's ace in the sleeve respect dp: skeletal animation blend is more versatile than dp. Dp is, anyway, a little simpler to setup for a new game (it's about to change 2 lines in 2 files). But I'm writing a guide about how to setup a complete environment to create games with fte, so no big deal!