ID:138177
 
Maybe add a Live! button next to the Host button in Dream Seeker?


[edited] And another idea. A 'Close All' option in Dream Maker... because if you open too many files at once, eventually you run out of memory and BYOND crashes... I reported that a long time ago and didn't get a response, either. But at the same time, if you're browsing through an icon library, you wouldn't want to reopen the environment and forget the icon you're currently looking at.
On 2/17/01 3:41 pm Spuzzum wrote:
Maybe add a Live! button next to the Host button in Dream Seeker?

Yep. I am still trying to resolve how the hub should be accessible from Dream Seeker. I've discussed it with Dan, at the GoB, and in other places, but still haven't come up with a satisfactory solution. Most likely we will just have a quicklink to the games/live pages from within a separate panel. But since we're not releasing new features anytime (too) soon, I may stew on it for a bit.
[edited] And another idea. A 'Close All' option in Dream Maker... because if you open too many files at once, eventually you run out of memory and BYOND crashes... I reported that a long time ago and didn't get a response, either. But at the same time, if you're browsing through an icon library, you wouldn't want to reopen the environment and forget the icon you're currently looking at.

Good idea. Are you still having the memory resource crash? I spent some time a month ago implementing some optimizations to prevent this to some degree. It is not failsafe, unfortunately, but on my machine I was able to open a few dozen files without any problem. The resource hogging is independent of RAM, incidentally. Ah, the wonders of Windows!
I know this isn't quite the same as the ones Spuzzum suggested (it's feature creep), but while we're on the subject of suggestions...

How's that 24-bit icon support coming along? I'm adding new cards to Una and some of the new ones have lots of nice colors in them. Problem is when I start trying to combine them all into a single dmi file. This would be by far the easiest method for my code, because then I simply have to use different icon_states for different cards. But the 256 (or is it even less?) color limitation for an entire dmi file is killing my colors.

I get the worst results when I import the 24-bit bmp files directly into the dmi file. It appears that the import/icon addition routine takes the colors from the first few icons until the palette fills up, and if later icons have different colors, tough - it uses the colors it already has. I've been fiddling with quantizing the icons down to various numbers of colors before import and get much better results, but it's certainly not ideal. I can live with it - either by using multiple dmi files for groups of icons with drastically different colors, using all original bmps, or quantizing down to an acceptable level.

Another strong argument for the 24-bit support (besides the fact that I want it, personally) is that a lot of people probably wouldn't understand initially what's going on when their colors aren't what they expect. Happened to me when I imported the blue card icons, then went to work on the greens - they came up all grey instead of green because all the colors were already taken. With 24-bit, of course this wouldn't happen. And besides, I don't think many people here use gimp-perl to easily fiddle with the colors of many icons and see what happens. ;-)

The only arguments I can think of against 24-bit are that it would take some time on your part to implement, and they're bigger so they would take more time to transmit to players. Perhaps supporting some compression like JPEG or PNG would be nice (there are freely available libraries).

Anyway, no rush really. Do what you need to do now and think about that later. I can deal with it for now and when 24-bit support is added, I'll go back and update my icons.
In response to Air Mapster
On 2/17/01 11:27 pm Air Mapster wrote:

The only arguments I can think of against 24-bit are that it would take some time on your part to implement
...

Yep, that's the big one. And of course the fact that, with our limited testing "facillities", I would doubtless break some existing support to sneak this in. But I'll keep it Listed.

My best advice for the time being is simply to use separate icon files for the different cards, which would at least give you a reasonable 8-bits per card. The only extra inefficiency is the transmission of the colormap, but the limitation in the colors is the crux of your problem anyway. Icon-states were originally intended to display different motions of the same object, so it seemed natural that they would share a palette (and convenient in the sense that you could change the color in all of the states by simply editing the palette). I admit that I didn't anticipate that these hi-color multi-state icons would be coming around so soon. I will see how difficult it is to at least have a "separate palette" option-- but I suspect that 24-bit support is really the only way to do things right.