Custom paletted image format without palette storage

[fingolfin]

If you can design great hardware, I applaud you, this is indeed a difficult task. Good luck with that. However, this thread is completely off-topic, so *at most* suitable for the Junkyard forum.
Sadly, now the tone has become less than satisfactory, too.
Finally, who we are: We are the people running this forum, and we set the rules. We do not have to prove ourselves, either, we already did that to our satisfaction by writing ScummVM.

I will lock this thread if it further deteriorates.

[kaveirious]

I'll keep it down in hope of a hardware enthusiast dropping by.

I believe that there is more computing than meets the eye.

To the point:
Why should i work with RGBA since i don't have (on the embedded system) a 24-bit DAC? It is not affordable (the system must be cheap, so on-board resources must be lean). I have two choices: 8-color VGA (15-pin) and easily up to 256/512 using simple R/2R ladder (have done this). The 24-bit DAC removes room from both maintainability (my a single person) and my profit margin. The RGBA concept (RGBA is a bloated goat yes) affects everything and especially the NAND Flash storage. Production costs go up.

Here nobody even helps getting started with a SCUMMvm virtual machine on hardware. You don't even have concise documentation on your precious. Only bits and bobs.

[sev]

Who are you that will define if this discussion is suitable for ScummVM forums or not?

[...skipped]

AND MOVE THE THREAD BACK.

I am one of ScummVM co-leaders. Fingolfin is another one. So we really have the right to set rules here. This post is complete offtopic. And no, I will not move it back.

moderatorial: kaveirious, you get a warning. One more moderators abuse will end you banned here. You violated Forum Rules #2, #3, #4 and #15.


Eugene

[seubz]

Hello,

I'm still curious about what sort of embedded system you want to use. You're saying that "we're blind" and come from a PC world. As an embedded systems engineer, I'm still confused about what you want to achieve. And we're all very conscious that there are other types of processors than AMD/Intel. You still haven't told us which processor you're using, if you're using a custom evaluation board you made, if you have a development board from a constructor, if you have already have an OS running on those, or if your environment is more constrained (like a processor with no MMU, or using a simple microcontroller). Maybe you're using an FPGA or CPLD as you were talking about a chip that can be reprogrammed or something like that...

And I'm also amazed by your thoughts on getting ScummVM to "hardware". ScummVM is a program, the only thing you can do with the code is port it to a platform. And you're saying there's no documentation ? What documentation do you need ? Like a description of all the functions in the source code ? I've been browing ScummVM's source for a while, and I'm quite happy with the way it's organized. I really don't get what you're trying to do, but with some clear information (which means something we can understand and believe), maybe you'll get some help. That also means not insulting the guys who are lead developers of the project...

Bye,
Sébastien.

[fingolfin]

Seubz,

I guess you can get a glimps at what he is up to by looking at the two previous threads he started:
http://forums.scummvm.org/viewtopic.php?t=4272
and
http://forums.scummvm.org/viewtopic.php?t=4289

[Vinterstum]

I'll admit I'm a bit puzzled by this whole issue.

If your goal is to implement a SCUMM interpreter in hardware, why focus so much on this specific issue? Surely the actual palettes account for very little of the space used by the various SCUMM games.

[kaveirious]

I'm still curious about what sort of embedded system you want to use. You're saying that "we're blind" and come from a PC world. As an embedded systems engineer, I'm still confused about what you want to achieve. till haven't told us which processor you're using, if you're using a custom evaluation board you made, if you have a development board from a constructor, if you have already have an OS running on those, or if your environment is more constrained (like a processor with no MMU, or using a simple microcontroller). Maybe you're using an FPGA or CPLD as you were talking about a chip that can be reprogrammed or something like that...

Check out development boards with FPGAs. I work mostly with Xilinx (have two, one bought by me, one at university, preparing to buy another), and Altera (have one at univ. office).

Xilinx: http://www.xilinx.com
Altera: http://www.altera.com

The processor is mine (unnamed yet). Originally designed for research purposes (has some unique capabilities like natively executing multi-input, multi-output instructions -- of DAG form). Now I'm writing some firmware.

My processor will not have an MMU (yet). It supports two different schemes for plugging in extended functionality. Examples that i have done: exponentiation unit, Euclidean 2D distance approximation (returns result in a single machine cycle) etc

I have also written (and presented) a tool that automatically extracts functionality blocks from regular ANSI C source code of the application of interest.

So, yet i'm using FPGAs to take advantage all their benefits, but especially rapid prototyping of my hardware designs.

[kaveirious]

I'll admit I'm a bit puzzled by this whole issue.

If your goal is to implement a SCUMM interpreter in hardware, why focus so much on this specific issue? Surely the actual palettes account for very little of the space used by the various SCUMM games.

I admit you have a reasonable point.

My aims are:

1. Save close to 4x in storage for images. (thus paletted against RGBA).
2. Avoid decoding image headers in software.
3. Have common way (thus the commonly inferred palettes) to generate/create new content.

The SCUMM interpreter (in hardware) is interesting from an engineering point of view. There are several examples of "old" machines on FPGAs but nothing as complex (intruiging as SCUMM or Q3VM or ...

[kaveirious]

Seubz,

I guess you can get a glimps at what he is up to by looking at the two previous threads he started:
http://forums.scummvm.org/viewtopic.php?t=4272
and
http://forums.scummvm.org/viewtopic.php?t=4289

I hope i am consistent with my previous threads. ^_^

I admit that (while i develop quite a lot of technical software using gcc, binutils, flex, yacc etc) my interest in SCUMM basically was playing the games (and getting up-to-date for this . I haven't written a single code for SCUMM yet, and this is a sin

But my (long-term) plans for writing not SCUMM but some game-related engine for explicit hardware support are serious.

[DrMcCoy]

1. Save close to 4x in storage for images. (thus paletted against RGBA).

Hmm, when you've got a series of 320x200 pixel paletted image data, you've got 64000 bytes each. In comparison, the 768 bytes of actual palette are neglectable...

2. Avoid decoding image headers in software.

I don't see how simple image headers are such a bottleneck that needs to be casted into hardware.

The SCUMM interpreter (in hardware) is interesting from an engineering point of view.

As someone who also plays around with FPGA boards (for a practical course related to the two "Chip and system design" courses in my uni) I really fail to see that. Hardware is practical when you have to do a lot of "number crunching", especially when the tasks are independant and can thus be done parallel.
Adventure engines commonly lack this.

[kaveirious]

Hmm, when you've got a series of 320x200 pixel paletted image data, you've got 64000 bytes each. In comparison, the 768 bytes of actual palette are neglectable...

I can do the math. You failed to read carefully my posts. The problem is the lack of VGA output of more than say 512 colors. Plus the storage of RGBA (take not) images. RGBA needs 4 bytes per sample (pixel). Paletted images need 1. I want to drop palettes for convenience of the RTOS.

I don't see how simple image headers are such a bottleneck that needs to be casted into hardware.

So your solution is to decode the BMP headers in firmware. Good, but you know there is a proble. I (unfortunately) have not developed the compiler. I have a DLX backend that i wrote during September-October 2006 for gcc-3.4.3 but i didn't maintain it, and it is difficult to port to newest gcc, and to make the changes for the new machine (has striking differences to DLX/MIPS and classic RISCs).

As someone who also plays around with FPGA boards (for a practical course related to the two "Chip and system design" courses in my uni) I really fail to see that. Hardware is practical when you have to do a lot of "number crunching", especially when the tasks are independant and can thus be done parallel.

I play with S3SK, S3ESK mostly. What boards do you work with?
I have also designed the S3ESK lab (the assignments) at my univ as lab assistant. Have you read the XCell54 paper on the 2600? Isn't it both inspiring and aspiring?

Yes, adventure VMs are probably control-dominated. Basic blocks can't be expected to be large with lots of parallelism. So you have to go to a higher abstaction level and move entire functions/procedures to hardware. In a sense that the older CISCs did. It is also a matter of mapping data structures (and dynamic ones) to hardware. There are at least three works that have developed hardware implementations of the ANSI C malloc() and free(). There is some reason for that.

Still, i'm looking for a SCUMM specification, complete. Then i can decide whether it is worth it or not. It sure is worth for the JVM. Lots of JVM hardware engines out there (picoJava, JOP etc). JVM bytecodes tend to be control-dominated as well. But it is also a matter of real-time performance. It is better constrained when having an all hardware solution (and precise interrupts).

-kaveirious

[Noelemahc]

Your comments (some) are only valid for the PC world. I design apps that do not run on a PC. Run run on a 4-5 Watt chip that can be reprogrammed regarding both hardware (what processor it emulates) and firmware.

Okay, then I shall retreat back into my small PC world. It's really scary outside of it, you know.

Plus the storage of RGBA (take not) images. RGBA needs 4 bytes per sample (pixel). Paletted images need 1. I want to drop palettes for convenience of the RTOS.

Returning to my initial post. Paletted images need one PRECISELY because the palette they use is defined in the header (or, in rarer cases, is part of a standard system palette, in which case this fact will be noted in the header anyway). The system you cited originally will need at the VERY least 2 or 3 bytes per pixel, for reasons which I've already outlined above. Unless I've again grossly misinterpreted your concepts (or you haven't actually done the real math on them). That may be smaller than an uncompressed RGBA image, but not as small as a 'common' indexed or a lossily compressed RGBA image.

[fingolfin]

Implementing Java Bytecode in hardware is interesting because it is a general purpose code, and there are tons of code for it out there, including number crunching code, and several big application.

The VM/bytecode of an adventure engine, however, is tightly focused on a specific task. It is not really suitable for writing general purpose applications. There is no big body of code for them out there either. Hence, implementing them in hardware may be a fun project, but not a very useful one. Sure, it's kinda cool, but it is IMNSHO the completely wrong approach if you want to create game content.

Finally, the notion of implementing something in hardware because it's too difficult to update the compiler seems odd once you leave a very strongly (small) focused area of computing (including number crunching tasks etc.). Hardware is relatively difficult to adapt. That's why we have software, for increased flexibility. Sure, not all hardware is capable of supporting a "firmware" or even an "operating system". But then, not all hardware should be used for all tasks . If your hardware is not strong enough to support a firmware, I think it's a rather... strange... idea to try to put an adventure engine on it.

OK, maybe in the 80s, you could have used to create an arcade machine and earn money with it, but these days, games become dated very quickly, and you don't want to tell customers to buy new hardware if they want to play a new game...

[DrMcCoy]

I play with S3SK, S3ESK mostly. What boards do you work with?

The ML310, mostly.

Have you read the XCell54 paper on the 2600? Isn't it both inspiring and aspiring?

Well, the adjective I'd use would be "trite". To be expected, considering it's just an elaborate advertisement...
In any case, it doesn't quite apply to ScummVM, since ScummVM is not an emulator.

So you have to go to a higher abstaction level and move entire functions/procedures to hardware.

...And you'll run out of gates/space pretty quickly.

But it is also a matter of real-time performance. It is better constrained when having an all hardware solution (and precise interrupts).

Functions in adventure engines seldom need strongly constrained running times.

[kaveirious]

Functions in adventure engines seldom need strongly constrained running times.

Of course, because the I/O can mask any such gains timing performance. I guess the only thing that might be better/easier in hardware (comparing to an embedded general-purpose processor not a desktop x86) would heavily loaded sequences.

That is, cut scenes with lots of sprites.
Or a demanding animation such as cloth,
the surface of a lake,
an exploding volcano,
morphs of various types,
a sport sequence (an instance of a soccer game that we would like to look like realistic),
plant growth,
army march,
etc

So if you design a customized engine it is possible to add hardware explicitly for such tasks. With a GPP (on the embedded system) it is not very likely that you can both achieve the computation and the I/O for these tasks.

-kaveirious