yea.. I've fixed the rel.link in the results post already the day the logo was changed (you had to point to another url for the dev7 results )

Let's at least hope the rom and ram size don't change..

Need to know the new specs right now

I'd relax the limit on max ROM size, let's say 512K like in the MRC contest.

That's really an artist question, less a coders question.

More ROM space -> more artwork, more maps, more music, longer music, more channels in music, msx2 alternatives, more sprite animation frames, etc. etc. And I personally think this artwork (minus map-design perhaps) is not the bottleneck of a game, it could be done rather rapidly..

ROM size seems the simplest thing to change without adulterating the spirit of MSXdev (MSX1 base compatibility).
We've seen good games in 32K and poor games in 128K so, why not leaving everyone free to choice ?

PS
ROM size is also a coding issue:

more room => less compressed data;
less compressed data => more on fly page swap;
more on fly page swap => more complex and animated games.

you can also try to store audio or video samples
and their packing and play is a bit more than a sole artistic question

mhoa, I'd tend to think that one would compress everything anyway, esp. as decompressing is a matter of ints.

Sometimes you do not have the time for decompressing (especially if you have to access the data during the ISR)
Having all data freely available in ROM could allow, e.g., an SCC PCM player to work in the interrupt routine.

You will agree that this kind of application cannot be realized using compressed data.

Actually also smooth scrolling cannot work without a good number of rom pages to be swapped on fly.

Rotated tiles have to be transferred to VRAM at each new frame.
You need to store them precomputed, and this can need lots of KB, as there is no time for unpacking them
Moreover they wouldn't fit in RAM, unless you do not want to rise the 16K-64K limit naturally.

256 tiles rotated in 8 horizontal positions take 49152 bytes for shapes and 6144 for colors.

Vertical rotation can be solved with just 24576 bytes and some pointer trick (256 shapes and colors)

For such applications raw access may be better indeed. I'm somewhat focused on the more traditional games, Konami style etc.

Ok, since the first entry of last year was one of the two winner games ... Maybe this year someone (I) should send the first entry!

Well, that best shooter winner was the one who submitted the only shooter of dev7. Anyway, afaik in dev5 we also submitted the only shooter (for which the prize was still not sent, and I doubt XL2s got their tR already), so perhaps the word 'prize' should be replaced by 'bonus', or 'reward', as 'prize' usually refers to a contest.

Quote:

mhoa, I'd tend to think that one would compress everything anyway, esp. as decompressing is a matter of ints.

That is for pure ASM a fact but other programming languages like C are a bit less flexible.
Expanding the ROM size would make things easier for some conding not in pure ASM. And as MSXdev isn't an assembly coding contest...............

Ah well.....

Isn't it rather easy to inline that decompression code?

Quote:

More ROM space -> more artwork, more maps, more music, longer music, more channels in music, msx2 alternatives, more sprite animation frames, etc. etc. And I personally think this artwork (minus map-design perhaps) is not the bottleneck of a game, it could be done rather rapidly..

Well, I must say that "more artwork" makes also the most of the WOW! factor when discovering a game.
We've been fed on big games with great artwork from Konami, wouldn't it be good to have that feeling again ?
The Nemesis trilogy was not build on a very original story, after all it is only a (great) shooter !
It's the story, the demo, the music, the levels and the artwork that made it what it is.

I say : MSX2 oriented - no ROM limit !

Quote:

Isn't it rather easy to inline that decompression code?

Yes but automatic dynamic memory management is the problem.....