MSXDev'07 specs - discussion

Página 6/23
1 | 2 | 3 | 4 | 5 | | 7 | 8 | 9 | 10 | 11

Por mars2000you

Enlighted (5515)

Imagen del mars2000you

27-09-2006, 21:42

pff...

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

mmm...

More difficult than the MRC megapolls ??? LOL!

Por Huey

Prophet (2644)

Imagen del Huey

27-09-2006, 22:01

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 .. Tongue

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

Por wolf_

Ambassador_ (9778)

Imagen del wolf_

27-09-2006, 22:04

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

Por Huey

Prophet (2644)

Imagen del Huey

27-09-2006, 22:10

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

Eek!

Por wolf_

Ambassador_ (9778)

Imagen del wolf_

27-09-2006, 22:14

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

Por Huey

Prophet (2644)

Imagen del Huey

27-09-2006, 22:20

You know what I mean Shocked!

Por drbyte

Supporter (6)

Imagen del drbyte

27-09-2006, 22:54

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?

Por Huey

Prophet (2644)

Imagen del Huey

27-09-2006, 23:18

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.

Por wolf_

Ambassador_ (9778)

Imagen del wolf_

27-09-2006, 23:29

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.

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?

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.. Tongue

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!)

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).

Did any commercial MSX-1 megarom use 'zip-style' compression?
Probably not, but I wouldn't know.

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 Big smile)

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 Tongue, but I'll post it when I have one)

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 Tongue

Por wolf_

Ambassador_ (9778)

Imagen del wolf_

27-09-2006, 23:31

additionally: what's typical compression? I'd say stringfinding. What if you put these strings raw in ROM and use them directly? MML music is like this. Technically it's the same practical effect as having comprsssion. E.g. there's no way you can ban compression! Not by restricting RAM, not by forbidding it.. Tongue

Página 6/23
1 | 2 | 3 | 4 | 5 | | 7 | 8 | 9 | 10 | 11