What if these questions are included in a poll? Then it would be possible to implement a votation system: every contestant will be able to vote once for each finished entry. Make it YES-NO questions and it will be a quite democratic solution

Hello everybody.

I use to read this forum, but I never have registered until now. I hope I can help with my points of view.
I'm specially interested in these things about the MSX-Dev rules. Maybe next year I decide to make an entry.
To start, I think is not premature to discuss about next year's contest. The rules for the current contest weren't discussed. The rules appeared suddenly. So, the same thing can be expected for next year unless people start talking about it.
Of course, who organize the contest has the power of setting the rules in the way their prefer.
But also developers should give their opinion. Developers are who make the great effort, who make a game or not. So, it would be nice if developers were allowed to say what they prefer for next year.
This is a forum, a place where people can express their opinions and suggestions.
As MSX-Dev is a great event, all arguments are interesting.

Quote:

btw, are you making any of those 'secret' entries or what?

Ahem!...still not enough "project" to be "secret", I'm afraid
Seriously talking, none of the projects I'm (very slowly) working on have reached the 75% of the main engine and for me it's a must; but who knows...

Remember: MSXtreme is the solution for all your MSXdev issues! Just C-O-D-E. Is there anything else than MSX? NOPE!

Seriously, I'm looking forward to see some of your projects! I hope that you'll make it on time!

for what it's worth:

1 - Do we need a specific MSX1 contest and a specific MSX2 contest ?

I think only MSX1 is nicer, but it's a hard question. I don't think that MSX1 and freestyle MSX2 should compete in the same group in any case.

2 - Do we need a special 'normal' roms contest and a Megaroms contest ? (this question is actually not the same than the first question)

Maybe, but only when you can expect a decent amount of entries in both groups. Additionally, makers of smaller ROMs could perhaps expand their ROMs with more artwork in order to make the game bigger? ( <- controversal, I know )

3 - Do we need to extend the RAM size for the 'normal' roms contest ? 32 or 64 Kb ?

please do And if ppl want a reason, they've been living under a rock yesterday

4 - Do we need to extend the ROM size for the 'normal' roms contest ? 64 Kb in other words ?

Together with the internal RAM, wouldn't that require a memmapper? 48kb ROM + 16kb RAM doesn't need a mapper, so *if* there is to be a limit, this would be a practical one. More than 48+16 and you need a mapper.. so the size of a game becomes less relevant.. 4M ROM? Why not? If you have the artwork and content for it..

5 - Do we need to add bonus points for extra features in the context of the 'normal' roms contest ?

Seems like a nice idea, at least that's why we add SCC music this year.. and some MSX2 palettes!

6 - Do we need to add penalties for games that can't be played on a MSX1 with only 16Kb RAM ?

Only if the rules state that 16kb is the minimum. If the rules state that one may use 32k or 64k RAM, then what's the point of giving penalties when ppl obey the rules?

7 - Do we need to add limitations in the context of a Megaroms contest ?
Such as? The more 'high-end' scene would like to squeeze every drop out of the possiblities, when a rule limits things to, say, 2M ROM and 16kb RAM then that's like having a creamcake with a 2meter radius, with only one small cherry on top of it.. how fun is that?

8 - Do we need to add limitations in the context of a specific MSX2 contest ?

Think twice before organising an MSX2 contest specifically!

9 - Do we need to create a system of pre-registration ?

Can't be realised. I'd only like to see ppl who'll participate saying that they're participate. Atm we're discussion this because Viejo's got worried about 'only' 7 entries sofar.

10 - Do we need to host on the MSXdev site also games developed outside the contests ?

That's up to you.. but I guess every internet site on this planet can host things that are free to host. But if you're referring to games like Dash/Lux .. well, dunno. That's all related to how you see your future. Do you remain to be only an anual contest? Or do you intend to become a gamedev portal?


pff...

2-1
0-3
2-1
2-1
3-0
3-0
1-2

mmm...

In any case, I highly agree with sjoerd on page 3, ROM-size defines the scale of the game, RAM defines the amount of terror for the programmer and gamedesigner. Raise RAM and make coders happy, I'd say ..

Quote:

pff... 2-1 0-3 2-1 2-1 3-0 3-0 1-2 mmm...

More difficult than the MRC megapolls ???

Quote:

In any case, I highly agree with sjoerd on page 3, ROM-size defines the scale of the game, RAM defines the amount of terror for the programmer and gamedesigner. Raise RAM and make coders happy, I'd say ..

Not for all coders The thing is with Hitech-C we only have 16kbRAM available. So we have to run the main code from rom

I can't imagine there isn't some smartass coder around who can hack it so offers more RAM ...

Are you serious? I don't agree. We're talking about making things easier for coders
This years 128kb ROM limit is the solution for us. Just like the more RAM will be a solution for your pro... ambition now.

well, we don't have a problem in the first case eh..

You know what I mean

As I can see, the RAM matter is one of the main points of discussion.

The ONLY reason to require more than 16KB of RAM is to uncompress and use data instead of using it directly from ROM. Not only levels, even CODE running uncompressed on RAM.
If no compression required, 16KB of RAM are enough. Even 8KB should be enough for most game concepts.

I'm not against compression, but we must realize compression has some disadvantages.
One of them is the processing time. To uncompress data for a map, a piece of code, a melody, or a graphic set you need time, maybe several seconds.
So, abuse of uncompression processes can introduce many delays for the player: Waiting to get the level uncompressed before playing it. More simmilar to slow disk-load games instead fast cartridge ones.
If this not happens, OK. But if uncompression makes a game slow to start to play, it should be considered as a NEGATIVE point.

Other point is that abuse of compression is a way to take advantage from games that don't use it. Developers that don't want to use compression have less possibilities of winning the contest. It seems no fair. So, if a limited amount of RAM is said at the rules, it should be maintained. It's a way of fair between games that use compression techniques against the ones that don't use them.

Games that don't use compression cannot take use of the extra RAM because they don't need it, so, it's unfair again to allow more RAM. More RAM only helps compressed games.
So, if 16KB RAM requires tricky programming when uncompressing, it's a matter the coders have to solve and don't complain about it.

As the main focus is to develop MSX1 games, the MSX1 style can be considered.
Did any commercial MSX-1 megarom use 'zip-style' compression?
When they needed more data, they increased the ROM size, not the RAM requirements.
MSX-1 computers with 64KB of RAM were manufactured mainly to load tape games.
This is not a tape contest but a ROM contest.
Did any MSX1 rom use more than 16KB of RAM? (I don't know, answer please)

So, a 1Megabit game that uses compression is like a 2Megabit game that doesn't use it. And the 2Megabit game may be faster as it doesn't spend time uncompressing.

Never forget that this is a contest. If you think a game will be much better by using 64KB of RAM instead 16KB, why don't develop it besides the contest? It will worth the pitty.
The MSX-Dev seems to try to help to make new games, not to avoid it.
Or another solution: Make the game a bit shorter in levels, and release another bigger version with all levels, out of the contest, using more RAM or more ROM.

It has been said that few RAM makes programming harder. And compressing and uncompressing is easy? No compression, no code for it, so, more easy, less code to type.

Is this a contest of games or a contest of compression techniques?
Will we have to 'zip' all the ROMs to check the real value of each one?

drbyte: The compressors and decompressors are freely available anyway. It's not some sort of secret. Konami used macro's for their levels. That's sort of compression too.

Quote:

The ONLY reason to require more than 16KB of RAM is to uncompress and use data instead of using it directly from ROM. Not only levels, even CODE running uncompressed on RAM.

A purpose for having the game run in the first 16kb block while something's unpacking to the 2nd block of 16kb is to have an uninterrupted game. If one has to use the game's 16kb segment then the game has to halt for a while.

Quote:

If no compression required, 16KB of RAM are enough. Even 8KB should be enough for most game concepts.

Yes, it highly depends on the concept of a game.. why would you want to exclude gameconcepts that would require a little bit more than this 8/16kb?

Quote:

I'm not against compression, but we must realize compression has some disadvantages. One of them is the processing time. To uncompress data for a map, a piece of code, a melody, or a graphic set you need time, maybe several seconds.

Seen Sphere or Wings? Each frame is decompressed on the fly @ 30FPS, it's done in less than an int, iirc. Each decompressed screen equals a whole gamescreen of 32x24 tiles. A gfx-set might require a little more, but still: when done well it's really not like waiting on loading from a diskdrive orso..

Quote:

Other point is that abuse of compression is a way to take advantage from games that don't use it. Developers that don't want to use compression have less possibilities of winning the contest. It seems no fair. So, if a limited amount of RAM is said at the rules, it should be maintained. It's a way of fair between games that use compression techniques against the ones that don't use them.

Not allowing more memory to prevent the usage of decompression isn't going to stop clever programmers, they'll still work with compressed data, it'd only take them more precious time which raises the chance of a game not being completed ( <- this has been my point for days already!)

Quote:

As the main focus is to develop MSX1 games, the MSX1 style can be considered.

What's MSX1 style, and what's not? Actually I couldn't just mention an MSX2 game which doesn't have an MSX1 counterversion (be it with less colors/sprites/scope).

Quote:

Did any commercial MSX-1 megarom use 'zip-style' compression?

Probably not, but I wouldn't know.

Quote:

When they needed more data, they increased the ROM size, not the RAM requirements.

This is open for speculation ofcourse, but I could imagine that back then a bigger ROM would've been cheaper than the extra time it'd take the programmers to create all kinda compression algo's. (could be complete bull btw .. I'm just guessing )

Quote:

It has been said that few RAM makes programming harder. And compressing and uncompressing is easy? No compression, no code for it, so, more easy, less code to type.

Download bitbuster (a popular (de)compressor from Arjan/Teambomba) sourcecode for free! (note, couldn't find the link now, if any , but I'll post it when I have one)

Quote:

Is this a contest of games or a contest of compression techniques? Will we have to 'zip' all the ROMs to check the real value of each one?

it's formost a game contest.. and if compression can lead to a more vast game then.. why not?


ps. welcome to MRC and its neverending discussions