Prev: HP50g won't compute integrals using infinity
Next: HP50g -> computing whether or not (mathematical) series converge, and, if so, which value to?
From: PixelOz on 31 May 2010 02:48
Hi, I was experimenting with modifying a skin for the Emu 48 emulator
and I have some doubts about the number of colors of the skins that
can be used. I've noticed that many skins are indexed .bmp files
(meaning that they don't use full 24 bit color quality).

I assume that the reason for this is that early versions of the
emulator could only use a lower number of colors for the skin. I
experimented with a 8 bit (256 colors) skin in the latest 1.49 version
of Emu 48 and it worked fine but I also experimented with a full 24
bit color (16,777,216 colors) skin and I found that it worked just
fine too in my first few tests.

Does anybody knows if there is a problem with using a skin with such a
high number of colors? Is it that in a newer version of the emulator
it started to support 24 bit color skins? If so since when it has such
support? Since which version?
From: Christoph Giesselink on 31 May 2010 18:44
Emu48 supports true color images since beginning. The reason for the many
256 color background skins is easy. Emu48 is quite very old project, I began
my work in 1997 ! on v1.0.

At this time Internet online time (calculated per minute, no flatrate) was
expensive and mostly very slow for private users. At this time I used a
28800 bps analog modem, resulting a transfer speed of < 2KB / s.

So I and my successors used 256 color images which are much smaller than
true color images.

And when you more go back to the Win48, the direct successor of Emu48, some
of the background files made in 1996. And further remember, some Graphic
cards of PC's made in the early 90'ies hadn't support true color support at
highest display resolution, or you personally reduced color resolution to
256 color or 16 bit high color resolution for speed reasons.

And just remember, the famous transportable data media at this time was the
3 1/2 '' disc with the huge capacity of 1.44MB !!!. ;-)

Hope this explains some of the curious decisions we made some years or over
a decade ago.

Christoph


"PixelOz" <pixeloz1(a)gmail.com> schrieb im Newsbeitrag
news:c7e2087b-03bc-4179-927b-49e7dc8d6603(a)k31g2000vbu.googlegroups.com...
> Hi, I was experimenting with modifying a skin for the Emu 48 emulator
> and I have some doubts about the number of colors of the skins that
> can be used. I've noticed that many skins are indexed .bmp files
> (meaning that they don't use full 24 bit color quality).
>
> I assume that the reason for this is that early versions of the
> emulator could only use a lower number of colors for the skin. I
> experimented with a 8 bit (256 colors) skin in the latest 1.49 version
> of Emu 48 and it worked fine but I also experimented with a full 24
> bit color (16,777,216 colors) skin and I found that it worked just
> fine too in my first few tests.
>
> Does anybody knows if there is a problem with using a skin with such a
> high number of colors? Is it that in a newer version of the emulator
> it started to support 24 bit color skins? If so since when it has such
> support? Since which version?





From: PixelOz on 2 Jun 2010 03:17
Oh that is really cool. Don't get me wrong I'm not complaining at all!
I was just curious about why so many skins were in 256 colors and I
though that it was that early versions of the program couldn't support
that cause of the color limitations of older PCs but it wasn't exactly
because of that, it was for a similar reason, a data capacity and a
data transfer limitation of older technology. Now I know with more
exactness the real reason and I think is rather interesting that the
program had the 24 bit capability from the get go.

The reason that I ask is because I created a high res, high quality
skin for it based on a modified script from the skin created by Jemac.
I used the best picture that I found in the web site of the HP 48GX
calculator and created a full 24 bit photographic skin with it. It has
the same vertical and horizontal dimensions as Jemac skin but I used
the very nice HP 48GX picture as a base texture and I cleaned the
display and color matched the screen to the synthetic display overlay.
AI also adjusted the dimensions and the position of the display and
buttons area so they match the script very well.

I addition I adjusted the position of the synthetic screen overlay and
the Annunciators in the script file to fit the skin better. Overall I
think that it looks very nice and very cool and I like it a lot. Are
you interested in it? I could send you a zip file so you can upload it
to the archive if you want to. I will include a text file in the zip
file crediting Jemac for the modified script.

This would be version 1.0 and it is the very first time that I make a
skin for Emu 48 but from the early tests that I've done with it it is
working fine so far. Do you want to try it to see how it works? I
think that it is time to modernize the program skins to 24 bit color
cause now the file size is not a problem anymore.
From: PixelOz on 2 Jun 2010 06:36
Actually I found out later on that there were other 24 bit skins for
it already. It is possible that Grokwik's Real 48GX 1.0 is very
similar to what I did but I tried to download that file and my 7zip
zip file program cannot open it. It tells me that the file is invalid.
I tried to download it several times but no luck, that is why I made
my own.

It is possible that his file is pretty good and close to what I wanted
in the first place. Do you know why this file doesn't work? His other
file the Grokwik's Real 48SX 1.0 unzipped just fine for me and it is
very cool.
From: John H Meyers on 2 Jun 2010 07:04
On 6/2/2010 5:36 AM, PixelOz wrote:

> It is possible that Grokwik's Real 48GX 1.0 is very
> similar to what I did but I tried to download that file and my 7zip
> zip file program cannot open it. It tells me that the file is invalid.

As does my 7-Zip (version 4.65),
but both Winzip (9.0 SR-1) and Windows XP's "Compressed folders"
are perfectly happy to Open, Test, and Extract,
and the .bmp images look fine.

I once reported a 7-Zip bug myself:
http://sourceforge.net/tracker/?func=detail&atid=114481&aid=2650812&group_id=14481

It was marked "closed" with no action - 'Unable to reproduce problem
because use did not see or find where to turn on "final results box"'

Apparently the reviewer never noticed that it's an automatic pop-up,
which always appears by itself.

"and there are not steps to follow in order to reproduce the bug"
(apparently the single step of using "test" on any .tgz archive > 2GB
is not clear enough, either :)

[r->] [OFF]
 |  Next  |  Last
Pages: 1 2 3 4
Prev: HP50g won't compute integrals using infinity
Next: HP50g -> computing whether or not (mathematical) series converge, and, if so, which value to?