Program request thread

[Spike]

I want to make a complex program in C#,but unfortunatelly I don't think I've the skills to make it.

So trying to get some skills to practice a bit, but I don't have any ideas of what to make. So if anyone have any ideas of an useful program that I could make and that people could use it that would be great.

[Imoddedu]

What do you consider yourself of making right now?

[coder0xff]

I know something that you could try out. I haven't had time to make it, so...

viewtopic.php?f=4&t=3153&p=400772#p400759

follow a few posts down where I talk about it a bit more. If you need help with implementation details don't be 'fraid to ask. I was thinking make a vector field in HSV color space and the direction/magnitude of a vector represents the shift in the color space. Use cubic interpolation for the interior of the set, and choose an extrapolation method for the outside.

[Terr]

Are you looking for a learning project that includes/avoids certain types of problem areas? For example, you might want to focus on a GUI, or leave that kind of complexity for later. Ditto on topics like multi-threading, network communication...

[xoqolatl]

Write me a benchmark. It should measure any parameter of computer system you like, should scale well (pick a scalable parameter!), should use less than 512 MB of memory, should output a single integer or floating point number as a result, results should be repeatable with at least 1% accuracy.

[Surfa]

Well I had this idea for a tool that Andy reject for it being beyond her knowledge and well I shit my pants thinking of attempting it. The idea is a tool that loads a .vmf files and reads all the brushes and models in a certain vis-group and renders them with lighting that replicates the in-game lighting. You can then edit the lighting settings and add lights etc. Then re-save as a .vmf. Obviously getting the textures for the brushes/models would be great although not necessary. Probably the hardest part would be getting the lighting to look accurate seeing as you wouldn't be able to bake in lightmaps in real time. Obviously if you believe this is beyond you skill level I don't blame you. But if you managed to make it I would love you forever. Also payment would be a possibility.

[coder0xff]

Well I had this idea for a tool that Andy reject for it being beyond her knowledge and well I shit my pants thinking of attempting it. The idea is a tool that loads a .vmf files and reads all the brushes and models in a certain vis-group and renders them with lighting that replicates the in-game lighting. You can then edit the lighting settings and add lights etc. Then re-save as a .vmf. Obviously getting the textures for the brushes/models would be great although not necessary. Probably the hardest part would be getting the lighting to look accurate seeing as you wouldn't be able to bake in lightmaps in real time. Obviously if you believe this is beyond you skill level I don't blame you. But if you managed to make it I would love you forever. Also payment would be a possibility.

A lot of the code needed to do this already exists. Actually, pretty much all of it except the lighting (which can be derived from the code for vrad) and a gui. All the loading/saving/mounting code is already written. The lighting could be near-real time and work through progressive refinement (which valves lighting lends itself to rather easily). Make a change and the recalculation occurs in another thread. Once it's done the solution is correct till you change something again, so you'd be able to fly around through the map and check it with good frame rate.

[Surfa]

Really I didn't think coder for the .mdl file format was released. I mean you could like reverse engineer it. Also small recompiles could work although real time would be much preferred. I mean changing the lighting settings whilst it updates would improve the workflow greatly. I mean the way you suggested is a improvement but it would still annoy me after using engines like the cry and unreal engines.

[vcool]

I think coder had a super haxor unfinished MDL compiler code, or at least I think he mentioned it.

At any rate, I know what Spike feels like, but I think the stuff you guys are discussing is abit over the top.

[Terr]

AFAIK the problems people have "decompiling" MDLs have more to do with physics, bones, animations, etc. For static props it probably isn't that hard to figure out how it would cast a shadow.

If you want sample code for finding out what materials an MDL uses, I've got that, since PackBSP has to be able to know what materials are required by a given model.

[coder0xff]

Yeah, I worked on an MDL decompiler. It does work somewhat, but like you said, it's incomplete. The entire format definition is coded though. jigglebones, blend animations, everything. It was while I was working on that the I completed the list of QC commands on VDC (for whatever MDL version was released with OB), yes it was some haxor shit.

The codes public, though. In fact, the module is hiding quietly away inside DuctTape just waiting for the next programmer to give it a UI.

[omnicoder]

Yeah, I worked on an MDL decompiler. It does work somewhat, but like you said, it's incomplete. The entire format definition is coded though. jigglebones, blend animations, everything. It was while I was working on that the I completed the list of QC commands on VDC (for whatever MDL version was released with OB), yes it was some haxor shit.

The codes public, though. In fact, the module is hiding quietly away inside DuctTape just waiting for the next programmer to give it a UI.

I can't seem to actually get ahold of the ducttape code off sourceforge, but where exactly are the relevant files? I started making a mdl decompiler but I'm guessing you already have more then I've done so far.

[coder0xff]

Yeah, I worked on an MDL decompiler. It does work somewhat, but like you said, it's incomplete. The entire format definition is coded though. jigglebones, blend animations, everything. It was while I was working on that the I completed the list of QC commands on VDC (for whatever MDL version was released with OB), yes it was some haxor shit.

The codes public, though. In fact, the module is hiding quietly away inside DuctTape just waiting for the next programmer to give it a UI.

I can't seem to actually get ahold of the ducttape code off sourceforge, but where exactly are the relevant files? I started making a mdl decompiler but I'm guessing you already have more then I've done so far.

Sorry there's only sparse commenting in here. Line 2407 is where the LoadMDL function is, though the path is immediately overriden. Still needs a bit of work.

http://ducttape.cvs.sourceforge.net/vie ... iew=markup

It's wrought with generics and custom attributes so that the data layout itself drives the formatter - it's powerful but it's not for the faint of heart. I'd be more than happy to help you with it, so feel free to contact me.

[Terr]

On the Java side of things (where being further from the hardware is actually a downside) I was hoping to use Preon for some MDL/BSP parsing a while back, but hit some bugs. (Now, however, I know the developer simply never checks his Sourceforge bug tracker )

'Course, now that I see the developer is still active, I may revisit it.