eezstreet

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.

@@ensiform supposedly fixed it, so I'm not sure. I suppose I could keep it at 512x512 as that's technically higher-res. @@DT85, what resolution are you using, and how long does it take to load?

Yeah, oddly enough the binoculars have the same world model as goggles do, which make things weird with g_binocrandomrate, and probably this RPG system. I don't think they could or should be combined, the binoculars were in Ep4 and they aren't really the same, plus the view is really different. If someone wants to make me a goggle overlay that looks better, I'll have no opposition to including a new one tbh. I just ask that they keep the same style and make it higher-res than the current one. BTW, I updated the OP with some new cvars + stuff. Still no word on a release timeframe. I need some assets finished.

This is really the wrong thread for that.

Right but I'd want to make that sorta thing toggleable, but there really isn't a way to do that with binoculars, unless maybe if you pressed the button to activate goggles again. Not sure. But both of those suggestions are kinda close to the goggles. I don't know if you can do a thermal view really well without rend2.

I was thinking about making binoculars and LA goggles more useful. I'm thinking for the LA goggles, you could pick up more of them later on, and when you pick them up, you effectively "upgrade" the goggles and binoculars, making them better. Some ideas of the levels: Binoculars Level 1 - Basically same as base Binoculars Level 2 - Brighter display, allowing for some light amplification Binoculars Level 3 - ??? Goggles Level 1 - Basically same as base Goggles Level 2 - Press Attack to toggle vitals display. In addition to giving you a small amount of light amplification, this mode also displays the health of humanoid targets, but drains more batteries Goggles Level 3 - Press Alt Attack to toggle heartbeat sensor. In addition to giving you a small amount light amplification, this mode also pulses and displays enemies through walls just some ideas