eezstreet

I'm an idiot, this code is really handled by the client and not the renderer. But in a surprising twist of fate, libavcodec supports ROQ format, so we can just use that and replace all the ROQ code wholesale, while gaining support for all those other formats in the list.

Oh wow, that looks really good! A few things that could be improved upon - the numbers/bar on the left could use a bit of touching up. It seems really sharp and bright in comparison to the other things. The black edges seem a bit too sharp, perhaps you could blur them a little bit. Also maybe you could touch up on the numbers at the bottom to display the range, so they're more movie-like? But that's a small point really and it does look good as it is now. Maybe add a small amount of faint noise to the black area so it appears to be textured? I do really like this though. It looks very good. I especially liked how you added the aurabesh text from the movies, I thought that was a nice touch. I'll have to see if I can make the battery bar green instead of yellow in order to match this. As for OpenJK JK2 mode, you just have to enable the "Compile with JK2 support" option on CMake (I don't know if buildbot builds with this option, I don't think it does), and then run with +set com_jk2 "1" in the .bat. It'll function exactly like OpenJK does now, but it'll run JK2 SP, and use JK2 assets as well as jk2gamex86.dll instead of jagamex86.dll.

erm...why not? It's supported on all platforms, for starters...

Assuming you're using OpenJK, change this line to: XCVAR_DEF( g_weaponDisable, "524279", NULL, CVAR_SERVERINFO|CVAR_ROM, qfalse )This defines the basic properties of a cvar. Note the difference of the stuff in quotes. This is the default value. Also note how I changed it from CVAR_SERVERINFO|CVAR_ARCHIVE|CVAR_LATCH to CVAR_SERVERINFO|CVAR_ROM In this particular case, the CVAR_SERVERINFO flag is needed in both cases, as it's responsible for telling clients on the join server menu that your server doesn't have weapons (for the icon thing). CVAR_ARCHIVE means that it gets saved to the jampserver.cfg, CVAR_LATCH means that it requires a map restart to take effect. CVAR_ROM means that the cvar cannot be changed ingame at all. So by changing the flags to CVAR_ROM and changing the default value, you're setting the cvar to a fixed default value that cannot be changed. You can perform a similar edit to g_forcePowerDisable as well. If you aren't using OpenJK, you can do this in g_main.c. The flags and everything are identical, there's just some slight syntax differences but it's nothing to worry about really.

@@Xycaleth, let me know when you you have run a profiler on rend2. I'll be interested to know what the bigger bottlenecks are.

So...potential creators of custom games, what sort of cvars would you be interested in? Note that I'm mostly working with items at the moment.

Yeah, probably. But I don't understand how you'd get depth data either way, actually. If you use only a single camera, there would be almost no way to determine the depth..right? Maybe you could run a simple calibration and then interpret the difference in marker size vs. baseline as the depth. You could also place two different cameras at a fixed angle and calculate the depth via some basic trigonometry. However facial features (nose) might occlude some of the markers.

This is pretty neat. I noted in the screenshot that there's a small black line (going through hilt, saber color). Is this fixable?

pls 4, is dark

I suggest we refactor the video code to be in rd-common, and load different formats other than .ROQ for the cinematics. The idea is that the video loader would operate similar to the way the image code is done, with something like: static const videoLoader_t [] = { {"roq", OpenROQ, StreamROQ, CloseROQ}, {"mpeg", OpenMPEG, StreamMPEG, CloseMPEG}, {"mov", OpenMP4, StreamMP4, CloseMP4}, {"avi", OpenAVI, StreamAVI, CloseAVI}, }; I realize that most of these formats are container formats, so I suggest we use libavcodec, which is LGPL (compatible with GPLv2/3, yes?) arbitrary tags @@Xycaleth @@Raz0r @@ensiform

I kinda agreed with some points and disagreed with others, as I recall. I didn't actually see the video again (can't atm) though.

With the source code release, it might be possible to get the actual menu and port it to PC, since they both use .menu and the same formats. The XBOX version used .gob files instead of .pk3s, and I think Gamecube did too. Only problem lies in actually making a .gob extractor. I think I started on one but never completed it.

It has more to do with the resolution the ROQ is being displayed at and the quality of input going into the ROQ.exe progarm more than anything, I think. ROQs in the base game are only created at like 256x256, which is really really small for something that's meant to be displayed fullscreen. Same deal for levelshots. Most of the base levelshots are really crappy in quality because they're created at like 256x256 (and are really low quality images to begin with I think too). ROQs are basically sequences that tell the game how to construct a series of TGA images. The process is entirely lossless, but don't hold me to that as I haven't personally examined the format too hardcore. If they're not, we can always pump really stupidly high resolution (think like 4096x4096) ROQs to compensate (though these will jack up the load times considerably as it doesn't stream the video at all, it's preloaded). If that's too terrible, I can see if I can port Theora video from JKG to rd-vanilla (or rend2). BobaFett wrote a very fast algorithm for streaming which is actually faster than what libtheora provides, but it's prone to artifacts. H.246 is the highest quality that I'm aware of, but I don't think that's open source or GPL-compliant (feel free to correct me if I'm wrong however). The cinematic stuff I believe is all designed to be modular to begin with, if I'm not mistaken.

I highly doubt it. These look pretty generic, heh.

Awesome. I think it might actually be appropriate to start up a forum area sooner than I thought. Probably with sections: News, Discussion, Custom Games. News would be where I put new releases and stuff like that. Discussion would probably be for like contributions and helping people out. Custom Games would be where people would share their custom games.

Agreed. Perhaps they could change it to white? Also I think perhaps the next/exit buttons on the bottom could use a better font perhaps as they look a bit similar to JA's. But I do like the background and the colors you used. It looks good.

MP4/MOV files pretty much require you to write your own codec and adhere to it. They're also a lossy (and BIG) format, whereas ROQ is lossless (and also really small - a normally 50MB chunk of video can be compressed down to like 5MB). ROQ is actually a very, very powerful format and can render quite well. It would probably be possible to rewrite sections of roq.exe to make it support conversion from MP4/MOV->ROQ, but you're going to have a loss of quality. Also @Razor couldn't get it to compile at all on Linux due to the complicated, out of date libraries being used by roq.exe. @@OlgO, yeah, that's how the text crawl normally works. I was going to take the text crawl from Episode 3 and edit it/convert it to ROQ so that the quality could be higher. I'm just having a hard time getting my ROQ to come out. :<

Are the deluxe maps part of the BSP? Or a separate file? By cubemaps, I mean environment mapping. Course, if that's supported without anything extra, I'll probably be happy as well. I see there's stuff in rend2 for "cube mapping" but I'm not sure what that is. My guess is environment mapping? By BSP format, do you mean RBSP or IBSP? I suppose you could add support for IBSPs as well, I don't see why you couldn't per se. I'd be behind supporting both formats as IBSP would provide many benefits in terms of graphics capability. Why such a low cap on the number of dynamic lights? And by shaders emitting light, I mean dynamic lights. So for instance, computer monitors on kejim_post and various cairn levels would emit blue light that flickers slightly on maybe one of the terminals. Also, what about the limits on vertexes? Is there any difference in the number of vertexes per object that's supported? Currently you can't go any higher than 1024 per object, which is a significant limit. I know you mentioned multithreading the renderer. Are there any significant bottlenecks in rend2 that limit performance with high numbers of vertexes? I believe you mentioned that ghoul2 transforms are a significant impact. Have these been alleviated at all with the prevalence of Ghoul2 being handled via VBOs (and therefore on the GPU)? Sorry if these questions are too much, I just want to see how much performance/graphical power I can squeeze out of rend2. EDIT: one other thing. You mentioned that graphics cards for years have been able to do non-power-of-two textures. Are there any significant consequences for disabling the non-PoT limit, other than perhaps load times? This could be quite excellent for things without mipmaps, as they tend to get stretched on screen in ugly ways.

Test the text crawl, if you could. I don't remember the exact filename in JKA - I think it's JK0101_SW.roq Thanks a ton.

Sorta yeah. It's about stuff that wasn't previously known, and after scouring the code, we discover new things that aren't widely known.

That's an interesting note, @@OlgO. However I'm kinda curious if they actually tested that, since even 512x256 causes massive load times.

I've been a bit more open-minded recently to this, and I've begun to look around and find the best method to handle this. Basically I've been thinking that instead of doing an MD3 head, Ghoul2 is perfectly fine as it does store raw vertex data. MD3 and Ghoul2 are actually very similar in format; Ghoul2 has some extra crap to it to handle dismemberment and bone-based animation, but the fundamentals behind the formats are very similar. So...basically I've looked into something like this: http://www.isca-speech.org/archive_open/archive_papers/avsp01/av01_110.pdf However, I'd like to modify this a little bit so that we use a Kinect sensor, which would track motion as well as depth. The idea is that we use a series of about 10-20 facial markers, which use unique identifiers. Then, you would record a series of dialogue using the Kinect sensor and a special program, probably relating to the actual dialogue in the game ("Stop that, Jaden!"). This would export a file, which would be read by the game. Then for each model, you would specify tags which would correlate to each marker, and the difference in the positions would be used. I'm thinking that we would have to modify the ghoul2 format entirely, as it's too jittery atm to handle something like this.

So I was wanting to poke some people's brains (Mostly @@Xycaleth's) to see what will be and won't be supported under rend2. Will we expect to see deluxe mapping? (what is deluxe mapping, even?) I see there's some stuff for cubemaps, not sure how you're going to proceed with it. Will there be changes/additions in BSP lumps? What about dynamic lights? Are these going to project shadows? Will shaders be able to produce dynamic lights? (blinking computer screens come to mind) I ask because I was going to hex-edit the BSPs in JK2 in order to give them some better visuals in rend2, as well as alter the shaders. I wanted to preview the changes on MP first, until we figure out how to proceed with rend2 on SP (read: I add in the preprocessor stuff required) I'm thinking about using the same code for rend2 on SP, just a preprocessor command to specify it as being SP instead of MP

The fix ought to be for MP and SP both, but you can test to see. Also, I was outputting at 1024x512 and getting severe loading issues. I wonder if it just hates non-square ROQs. Regardless, I need to re-render my ROQ frames because I'm an idiot and overwrote my originals. :<

I wouldn't prefer a 1:1 copy. Go play DF2 if you want DF2? This updated version looks nice, imo.