Forum Replies Created
-
Posts
-
Looking good!
How are you doing the music?
> If this is possible it could be a good solution for automation.
This wont work, because the munging needs to be done on the mx2 function, and since a function pointer can point to *any* function the compiler can’t know which functions to mung, eg if the compiler sees a function such as:
Function MyDebugDraw( p:cpVect Ptr,…)
Should the compiler use ‘const’ or not? It doesn’t know if it’s supposed to be used with a debugdraw function ptr or not. It *probably* is – although even that would be hard to work out – but it can’t know for sure.
I’d recommend doing things like this if possible:
For each layer:
Draw unlit background (if any)
BeginLighting
Add lights and draw any opaque/alpha stuff that needs to be lit.
EndLighting
Draw non-additive particles (if any)
Draw additive particles/fake lights.
Draw unlit overlays (if any)
Next
Drawing particles/fake lights inside lighting should still work, but it will incur extra overhead.
> Can I do a loop like in this pseudo code?
This should work fine, just remember that EndLighting() clears out all add lights and shadowcasters, but that’s generally what you want if you’re doing ‘layers’.
Beats the hell out of the old ‘renderer’ system doesn’t it?
Nice hack! But it’ll mean you end up with 2 unrelated cpVert classes wont it? Perhaps that’s not a problem though, or perhaps it’s a rare enough issue – it should only be a problem with function pointers like this I guess.
I guess the user can always cast a const_cpVect Ptr to a plain cpVect Ptr if they only want to deal with the 1 type. In fact, perhaps const_cpVect should be ‘anonymous’ and they should have to do this? This would be easier to automate anyway.
Adding in per-bullet lighting quickly spikes usage and with 100 or so lighted bullets the GPU usage will zoom to 65%.
That’s still pretty cool!
My plan is reserve per-bullet lighting to special weapons that tend to be a single bullet object.
If it’s a rapid fire type game, how about using a real light for the first bullet fired after some timeout, eg: 1 second? Would make the ‘head’ of the bullet stream stand out a bit.
Just looking into some of these issues right now, and have it mostly working.
The tricky bit at the moment is comparing variants, so for now I’m going to leave comparisons as simple ‘identitiy’ comparisons.
This means 2 variants will only be equal if they are the *same* variant, not just 2 variants containing the same value.
Ok, a fix for this is now up.
A couple of notes:
- Alpha is taken from the diffuse map so normal map can be a 24bit png. Ideally, normal maps should probably ‘blend to’ Color(0.5,0.5,1.0) where alpha=0. This value represents ‘flat’ in terms of normal maps.
- Specular map is monochrome (only red channel is used if png is color) so can be an 8bit png. Specular actually ends up in the normal texture alpha channel so bump mapping only involves 2 textures.
Ok, interfaces are in but not well tested!
Ok, that should all be working pretty well now, have a look at the updated echoserver_udp banana.
You can’t yet, only non-extern/non-generic classes are fully implemented right now.
Other types can still be used with variants (so can be used as invoke parameters/return values) but will generate an ‘Unknown’ typeinfo.
Interface support should be pretty easy to add, but support for generic types is a while off yet and I suspect that’ll be what you need next!
It might still be a bit dodgy – finding a few issues on Mac. Will keep hacking tomorrow.
Ok, udp is now in.
I’ve added an echoserver_udp banana to give you some idea of how to use it.
I also modified the socket architecture a bit which may break existing code if anyone’s using it, but nothing major.
If memory serves Monkey 2 is using EFFNET?
Nope, never heard of EFFNET.
Monkey2 currently only supports IP4/6 TCP sockets, which should be easy to make work with client/server UDP so I’ll have a go at that now.
Should be fixed now.
