Ok, I've been trying to think of a way to present this feature idea in a way that would proof it from getting responses of, "That's impossible-at-this-time/impractical-at-this-time/not-needed/ who-the-hell-are-you/how-do-i-put-my -hello-kitty-game-on-byond" but I can't figure a way, so:
On a scale of 1 to 4 bowls of spaghetti code, how impossible would it be to create a new control that:
-that is transparent (for instance, can be placed over the existing map control with the map control showing through)
-that is updated using the client's processor
-(!possibly!) allow double buffering by allowing creation of two of these controls per client
-that uses a new class of /image that:
-do not split full sized image resources into 32x32 chunks
-do not need to be connected to an atom of any sort (only a client)
-can be blitted full-sized to any coordinate in the new control (using the client's processor)
(IOW, something like clientImage.draw( '128x256 hud element.png', x=127, y=30 ) would draw the full sized image to just one client )
-that would clip the image at the control's borders
-could be created as proper datum (allowing hooks and overriding of procs to handle mouse input, etc.)
The advantages and opportunities I can see are:
-decreases the server overhead for hud objects and other single client images
-increases ability to create faster alternate display games
-open byond further to arcade-like, single player game development
-could possibly have mouse input functions processed on the client-side as well
-bypasses the obj limit by creating a new class of obj
-simplifies many 32x32 to non-32x32 graphics issues
-bypasses the need to entirely change the existing map control
-would maintain backwards-compatibility of existing code
I dunno. I was thinking how you guys ran into client-side-processing snafu a while back and how neat that would have been. I was attempting to find a good way to incorporate a new avenue for this to happen and that's what I came up with. Of course, I have no idea how the code is structured and no idea of how difficult this would be.
I'm kinda loathe to present feature requests because I know how hard youse guys work on this behemoth, but maybe this control would be worth it. I just figured a straight up client-side image buffer would be a low-level change that could open up a lot of possibilities for Byondo. More bang for the buck, as it were.
Cheers.
ID:133690
 Mar 17 2008, 8:44 am (Edited on Mar 17 2008, 9:04 am)
|
|
-that is updated using the client's processor This is what killed it. This is what pushed your idea from a snowballs chance in hell to completely impossible. | |
Obs wrote:
This is what killed it. This is what pushed your idea from a snowballs chance in hell to completely impossible. No. Don't think so. It was mainly the transparency and layering, apparently. | |
TheMonkeyDidIt wrote:
Obs wrote: No way, there is absolutely 0 chance of support being put in for client-side procs. But transparency and layering are all perfectly possible right now in BYOND. | |
Lummox already posted on this matter, and he said it's already handled on the client side, but the transparency and layering can't be done. <_<
| |
Popisfizzy wrote:
Lummox already posted on this matter, and he said it's already handled on the client side, but the transparency and layering can't be done. <_< The most significant of his demands was client-side procs and objects. Of course, there are things that are already handled client-side, but those are things that BYOND dictates, not an actual game creator. Client-side procs would basically allow for making prettier looking games. | |
The topic title is even.. confusing
If something is 'impossible' then it's impossible, it cannot have a degree of impossibility. (Does anyone else understand where I'm coming from?) :D | |
So far these run about a 3 or 4.
Typically any adjustment of size, redrawing, etc. is already handled by the client, so 0 in that sense. As far as receiving information on what to change, that has to come from the server like everything else.
6. Our control layering is limited at best and to accomplish this sort of thing would basically mean having some means to change Z order reliably and permanently, or rapidly switching the images to visible/invisible.
Any PNG will already behave this way in an image-displaying control.
Blitting a single image to a set of coordinates is easy. If you're talking about blitting multiple images as a kind of replacement map, I'd put that in the realm of almost totally impossible.
That part's easy enough.
Controls really aren't linked to datums in any way so to do that you'd need to set up procs designed to auto-apply winset() or winget(). They're completely separate concepts but you could in theory build a library to link them up.
With what I've learned on the previous interface stuff, the opposite would be true. There'd be more overhead to send updates because it'd have to be done through soft code, and the images would be severely flickery.
Overall it'd actually make a lot more sense for us to do this kind of thing in hard-code, and by drawing stuff onto the map along with everything else. Our drawing routines are pretty decent, but Windows really doesn't like the concept of transparent layered child windows.
With controls it's kind of a crap shoot what works well and doesn't; if you've done Windows API development you know it's got lots of little quirks. One of those quirks has kept us from effectively maintaining a given Z order and therefore has kept us from manipulating same. Transparent controls are also quite problematic.
Lummox JR