Xycaleth

What happens when you try to run it?

Possibly a bit late, but if your FPS dropped when there were a lot of effects on-screen (including saber sparks), then I've just fixed these problems in my latest commit.

No, Boba only made it show a loading bar. Didz was talking about loading stuff in the background while you're playing the game.

Forgot to reply to this post! It should be possible to make a Mac version of MD3View. I did have plans to integrate MD3 formats into ModView, but ModView itself is on the back burner at the moment as I'm struggling to find time. I do hope to come back to this at some point though.

You haven't started the game yet... Like I already said, jagamex86.dll doesn't get loaded until you start the game (I.e. Start playing on a map).

Fixed that for you See this for example:

I guess I didn't make my point clear in my previous post. It's fine that it's trying to load the MD3 model using the Ghoul2 function. What's not fine, is the line I mentioned. What should happen is that ghlInfo->currentModel->data.glm is NULL, so it doesn't go into the block that you posted with the screenshot, and nothing happens. Also, you shouldn't ever need to check if data.glm->header is NULL - if data.glm is not NULL, then data.glm->header will always be valid. If data.glm isn't NULL, then it sounds like it's not being initialized correctly.

I've found in the past that MediaWiki as a wiki software is a bit of a pain to work with in terms of administrating pages, customizing, etc. Is this what you're finding, @@Circa? Perhaps there are alternative wiki software out there which would be more user-friendly. We should definitely make a back up of the wiki at some point though (if backups aren't already made). I've seen some people have made huge contributions to it and I'd hate to see all of that lost. JKG had an extensive wiki in the works while we were developing it, but after an unexpected server problem, we lost over a hundred pages of pages - not just information, but documentation as well.

@@Scooper #PlzScooper

And it could be done entirely in the renderer. No changes to the client game would need to be made which makes this a very appealing change Just need some sucker one to add it in...

If the mod doesn't work in retail JKA then we've messed up

Apparently it doesn't work at the moment

Looks like it just tries to load the MD3 model as a Ghoul2 model regardless. It shouldn't get that far though. It looks like this line is wrong: if (ghlInfo->currentModel->data.glm->header)It should be if (ghlInfo->currentModel->data.glm)

Oh okay, awesome. Having some coding experience will help a lot. If you want to know how to compile the code, you can probably download the OpenJK source code and then follow this guide on how to compile it. When you're running the CMake GUI (I'd recommend using this method of generating your project files), you can untick the options that build the engine so you only have to worry about building the mod code.

You would be better off if you started learning to code first before you dive into the JA source code. Coding isn't something you can pick up in a week and suddenly expect to make the next amazing mod. You need to spend at least a month just learning to code, and even then you'd be limited in what you can do. Searching the interwebs for something like "programming in C" or "C tutorials" should bring up some useful results.

I think this was either because the hashTable is getting uninitialized when you load a map, or because it's in the server-side code and the hashTable hasn't even been initialized.

Is that where his eyelids are being stretched to 0, 0, 0? I haven't figured out what causes the problem yet :/

Can you copy and paste your debug output log (the little window in Visual Studio)?

Are you checking after you're in-game (i.e. not sitting at the menu)? The dll isn't loaded until you start playing.

Yep

Oh, broken in this case means not finished as far as I know. SmileTheory said he had it working kind of, but frame rate was horrible.

Is it broken? It's not casting shadows because that code was never finished in the original rend2.

You could do that but it would be a lot more work than just converting manually by hand. As far as I know, the only C++ features they used is classes which can be transformed very easily into regular C structs: class Foo { public: int x, y, z; void DoTheThing(int n); int DoTheOtherThing(int a); }; Becomes: struct Foo { int x, y, z; }; void FooDoTheThing(Foo *this, int n); int FooToTheOtherThing(Foo *this, int a); I think you mean C++ is a superset of C (though even that isn't strictly correct either )

That's exactly what I'm in the middle of doing right now - porting the Windows build to SDL. There's a fair amount of code behind the SDL integration into JKA, so moving to SFML just for the sake of it isn't really worth it. SDL already does everything we need (and more). Both the Ghoul2 and ICARUS code are a bit messy and it would be good to see them cleaned up/streamlined, as long as all the same functionality was kept. Ghoul2 is more of a collection of formats - there's GLM and GLA for models and animations respectively. GLM stores the model data and GLA stores the skeletal animation data - so yes, normal meshes can be converted to GLM. LLVM has nothing to do with it actually. Originally in Q3, SoF2 and JK2, the cgame, game and ui modules used to be compiled down to byte code using a special C compiler (LCC - Little C Compiler I think it was called) and stored in "QVM" files. When the .qvm files got loaded, they were then JIT compiled into native machine code. This made it possible to compile the cgame/game/ui code once and it could be run on any platform. The downside is that you're completely sandboxed in - you have no standard libraries, and you rely solely on the engine to provide all of your interaction with the outside world. So you couldn't even use C libraries etc. JKA did away with all of that and just use DLLs. Players can use different cgame DLLs. All "behaviour" code is run by the server; players have extremely limited input into what happens in the game. In fact, the only input the player can send to the server are movement directions, their camera look angles, and which "fast-tracked" buttons they're pressing. There's a sideband channel for 'reliable' commands as well which are where the console commands get sent to. The client is essentially a dumb visualizer for the server. That was possibly be me except I tried integrating the Newton Dynamics physics engine into JKA before the engine source code was even made available. I stopped because I couldn't get the level of integration I wanted through just the cgame/game modules. It's a big job - I think I estimated around 2 months for someone who actually knew what they were doing. Sounds good