XL2s cancels their MSXdev'06 entries

Very sad news indeed, as it comes after TNI withdrawal from the competition with another ambitious project (Cyberware: Chapter IV ~ Katarsis episode II ~).

But the challenge is not over and all the projects are not yet revealed, some of them are still kept secret. MSX fun must continue !

Guess it's almost impossible to develop a 'big' game in one year time.

I hope they will continue and release it in the MSXdev'07 (if there will be one). And if so; MSXdev-Guys PLEASE do not set the requirements any higher. Just stay with MSX1, PSG and 128kb ROM. More possibilities will only lead to more cancelations.

Perhaps those cancelled entries means that bigger projects are more difficult to finish... this makes me wonder if we were right or wrong by extending the size to 128KB... anyway, time will tell!. Let's wait for the end of the contest and its final results before making conclusions out of this. C'mon, msx-ers out there, there is still time to finish/make your entries!

@Wolf!: I know what you mean. But the 128kb ROM does help a little. No matter the limits you always want to use the resources to the max. And there's the problem.

I'm glad we didn't enter the MSXdev yet. We won't be even close to finishing our 'little' project when the contest closes at the end of this year. Let's hope MSXdev'07 will come and doesn't stretch up the requirement limits.

These days it possible for almost everyone to make a game that can compete with the Konami game standard, or even surpass. But almost nobody has the time to make such a game in a/every year.

And PLEASE discuss the RAM issue I dunno whether 32kb msx'es actually are out there.. seems 64kb is more conventional. But as I said: this 16kb thing actually limits things and forces us to create extremely optimized/hacked solutions. Which is all a nice challenge ofcourse, but it does limit things. And I don't ask this for ourself actually, don't ask how, but I think our plans *just* fit 16kb. It's mainly for ppz out there who are less handy with optimizing code and squeezing basketballs into piggybanks (which pretty well describes our game ^_^).

Apart from that, how many ppl truly use an MSX1 with 16kb? A poll would be nice.. I estimate that an MSX1 with 64kb is as cheap as a candybar these days..

mhoa.. dunno. You could argue whether 'getting a price' is required. I think it's healthy, in a creative way, that if you are competent enough to win, that you actually try to win. If you don't see yourself creating the next Konami game, then that's no shame ofcourse, participating is also fun, and all the games from '05 were appreciated. Too bad that both TNI and XL2s could've been these so-called 'competent entries'..

I'm going for a 8 KB ROM!

I do not know, as so many games are cancelled, maybe it could worth an extension of the deadline or a specific sub-competition with extended deadline dedicated to the projects in delay.

64kb RAM and 16 or 32kb ROM? wtf That's like having a skateboard and a 400 square mile area to cross.

128k ROM + 32kb or 64kb RAM, would be the most ideal config. And this is a maximum config, no-one is required to fully use whatever there is..

Exactly, you need RAM for unpacking. But there's no point in having 64kb RAM for 16kb worth o' ROM stuff. I figure 32kb would be more than enough already for most stuff tho. Hence: 128k ROM and 32kb or 64kb RAM .. that should do the trick!

79%? suits me Viejo/Mars/Pitpan.. ya reading this?? a whopping 79% ^_^

If the MSXdev team wants to change the RAM limit for the '07 competition. I only hope they will decide soon. There are lots of people already doing stuff for next year (I think).

But I think it's safe to assume that most MSX users that still use a real machine these days, have a machine with at least 64kB. 16kB or 8kB machines are very rare and so unusable (they often lack other features as well) that I think you will reach over 99% of the real MSX users when choosing a minimum of 32kB RAM (for some Yamaha CX-5M users ) for a game.

The MSX standard is supposed to work with banks of memory.
If a software make a search in each slot and sub-slot, it should use external RAM cartridges. I know it is in the MSX standard! A lot of magazines and books makes references to this type of expansion, even the manufactures had original RAM
cartridges. It is on The Red Book!

There should be more than just two programs that could use the extra memory!

rather making a program that would work on 'any' MSX.
My first MSX (and most MSXes in my collection) was a Yamaha CX5M with 32kB RAM. It was quite boring at the time since many games required 64kB RAM. Most MSXers nowdays have at least one MSX with 64kB ram. I don't see any big need for the entries being compatible with lower spec MSXes so I think its fine to allow 64kB RAM in MSXDEV.

@dvik: Guess everyone is also able to run an MSX2 configuration too

IMHO:
128 kb ROM -> more possible -> cancelation of entries
32 kb RAM -> even more possibilities -> more cancelations

It really isn't possible to make big/complex/advanced games in 12 months.
The RAM expansion would make things a lot easier (even for me) but in the end you wil go to the max and would really need 64kb RAM (and so on).

The reason why (almost) all of my/our projects in the past never got finished was all the hardware that was available. It was just too much work (gfx/music) or even impossible to realise the stuff we came up with (Z80 can' t do everything at the same time).

How many quality MSX-scene games are there for MSX2? And how long did it take to develop them?
And how many quality MSX-scene games are there for MSX1? Thanks to the MSXdev we have a fair amount of them in only a couple of years.

t00b: read the rules again: The idea of this year's MSXdev is that it works on all 16kb msx'es and up, but additional support for e.g. soundchips, msx2 etc. gives bonuspoints. So, upwards supporting stuff does count, this year.

The ROM size defines the size of the game, the RAM size defines how easy you can code things. 16kb means lotsa hackjobs, and it could mean things are quite impossible. 32kb can just mean the difference.

Anyway, no-one is forced to use the full MegaROM ofcoz, if ppl want to make a 16kb ROM ... then they're welcome to do so!

Sofar XL2s are the only ones to cancel their entries due lack of time .. so let's not superimpose this single cancelation on the rest.

Pah, 16 hours is enough for 2 persons. (code-person and art-person) Dunno whether it's enough for one do-all person tho..

what's up with Dash? I thought it was nearly done already?

I must be dead slow then

All roms can benefit from 32kb..64kb RAM. But only when content is stored compressed in ROM (like UU). If old Konami games would've been compressed then they would be much smaller!

RAR'ed versions of MegaROMs (128kb):
F1-spirit -> 82kb
Usas -> 91kb
Nemesis 1 -> 53kb (!)
Nemesis 2 -> 89kb

2MegaROM (256kb):

Shalom -> 161kb
Space Manbow -> 150kb

4MegaROM (512kb):

Metal Gear 2 -> 310kb

To me this all looks quite raw'ish, concerning that quite a chunk can be compressed out. While I dunno exactly how much RAM these games require, I wouldn't be surprised if most of MSX1 games would work with 8kb already.

And now our own UU: from 48kb to 42kb .. but without us bitbusting the whole lot in advance, our game would be 112kb, that's almost a MegaROM already, e.g. more than twice the size of our ROM (little less than 3x, even!)! So, if we would be able to do a MegaROM, and we'd have the game's ass bitbusted again, then we'd prolly come close to a 2MegaROM, or even a little more than that! So, ofcourse there are benefits from compressing, but only if you have enough RAM to unpack to. 16Kb is always a bit of a hackjob, since you run your game in that 16kb as well, you can't just unpack a chunk of 16kb during the game without messing up. With an additional 16kb block (e.g. with 32kb RAM) you can! Therefor I think 32kb should really be enough, tho I'm not against 64kb ofcourse ..

Difficult to say isn't it. Count every screen of 704 bytes and you easely pass the 100 kb.
Then you still need to add gfx, music and code.
So lets say 150 kb (could be completely wrong here).

If you need more Ram, you are bad coder.

That's two mistakes in one line

- It has nothing to do with code, but all with music, gfx and maps.. so in short: artwork
- it has nothing to do with being bad, but all with being ambitious.

Is it really relevant that Konami could put MoG and all those other 128k into MegaROMs? We could also have put UU in a MegaROM. What's really relevant here is that we'll try to fit a 2MegaROM into a 1MegaROM. So the comparison won't be with MoG, Nem1,2, Sala, Paro, F1 etc., but with larger games, like Nem3, SpManbow etc.

Huey, without revealing too much of the game (it really should stay a surprise ^_^), the maps require quite a chunk o' mem. Basically about everything is compressed in ROM, the only elements that aren't compressed are raw things which are so small/random that compression won't make them smaller. It also saves on RAM since you don't need to reserve space to unpack those things to.
We've not yet looked into the final music size, there's somewhat of a player already, but it's still raw 8-channel music with multiple events per step .. so uhm.. 'big' ^_^

I think the 16kb RAM limit has it's charm. It's very MSX.

No, it's just very small, it would make sense in the early 80's when ppl wouldn't be doing compression anyway, and back then was the time of small games. In any case, our game *will* fit 16kb RAM, it's just a major timeconsuming hackjob, that's all.

Ambition is a good thing but it does tend to be on/over the edge of the posibilities (especially with MSX)
Ambition is king! It's the force that increases quality. Therefor it's commendable when ppl start on large-scale projects.. it's just too bad some of these projects won't make it in time. The one thing you have to calculate is not: 'is the game too big to finish?' but 'is the game too big to finish for me?'. As long as ppl stay honest about their own abilities, then everything will be ok. (not counting technical issues like with TNI's entry)

The limited amount of ram makes the choices between raw in rom, compressed in rom with unpack in ram and compressed in rom with on the fly unpacking a juggling act. It'll probably work out, but it takes quite a bit of time. I'm sure that things would get simpler with more memory available. Having a 128k mapper available would significantly cut development time.

That said, I do think you need more time for megarom entries. A full year would probably be good (note that we only had have 8 months this time). I think we can get it done in time, but the extra months would have been welcome to work on polish and lift it quality to a professional level. But even that amount of time may not be enough for as we don't all have the same amount of time to spend on hobby projects.

I do like the megarom projects though. Even though development time may be longer and there mey be less entries of this size, it gives a whole extra dimension to the type of games that can be created. I personally would like to go back to the smaller size. While making UU was fun, the battle for rom space limited us more than we liked in some places.

Oh yes! My english is very very poor and bad. It's a "internet english". But ... do you understand me? My native language don't is english. Sorry.

It's readable, no worries, I don't think anyone on MRC ever complains about bad English anyway. But a potential problem is when you pick the wrong word rather than picking the right word but then full of typos. In this particular case the problem was 'code' vs 'art'. Code is never extemely big, most content is artwork.

Well ... Whats the matter for make GOOD artwork with 16k of Ram? I don't understand this. Ram is Ram. For vars, etc ... artwork don't need Ram, need ROM.

I explained the compression thing, did I? If you use artwork straight from ROM the you don't need RAM, but if the artwork is compressed in ROM, then you need RAM to unpack it to. By having things compressed in ROM, you can have around twice the amount of artwork in your game.. that's the whole point.

And is that good? Well, consider this: a full sc2 screen is 12kb, that's 3 'parts' of 4kb. If you have more ROM due compression, you can take the option to have a full-screen titlescreen, if you have less ROM (because the artwork is raw in ROM) then you might have to reconsider, for ex. to have only one block of 4kb and thus prolly have a less nice titlescreen.
There are countless considerations like this to do.
Another one is music: PSG takes 3 channels, PSG+SCC takes 8 channels, this means the music is almost 3x as big! It would be a bit of a pity to have the 8-channel music raw in ROM, knowing that especially music has a lot of repetition! Repetition that would usually be packed away.

Ambitious? Yes, ambitious is make good game with only 8k of Ram.

I don't see why this would be the only ambition. With 8kb RAM it's not only about ambition, but also about practical facts. You aren't going to get a huge compressed game running with 8kb RAM.

Sorry, but VCS 2600 have 128 BYTES of Ram. Coleco Vision 1k of RAM. And this consoles have GOOD games. Please, you can see BattleZone or HERO in VCS, and this is GOOD GAME and ambitious.

Just wait, and you'll see that our game will turn faces of former Japanese MSX2 game producers.. I don't think we can compare that with those old consoles.

You are wrong. MSX1 don't is SNES or Amiga Computer. MSX1 is MSX1

Right, but what kind of MSX1? 8kb? 16kb? 32kb? 64kb? That's all MSX1!

But ambitious don't is use 64k of Ram for UU.
Well, 16kb was enough, was it? The only thing I'm saying is that with at least 32kb things will get easier for programmers and gamedesigners, which could raise the chance of succes.

Hi!

@Wolf [sc2 full screen problem]:

Well ... I have a bitbuster modification that only uses ONE BYTE of Ram for unpack files to VRAM. If pack file is in Rom, I don't need Ram. Yes, this modification is very very slow to decompress a sc2 screen, but if you use this for title, you don't need speed. One byte, only. Other modification only uses 2k of Ram. And with a special program to split SR5 file, I can decompress a SR5 file (27136 bytes), using only 2k of Ram.

I can make MSX1 and MSX2 game, using only 2k for decompress, with speed. (And if I need ram, i can use "one byte" mode).

Music? Well. You can make music files with semicompression. You need CPU but don't need Ram for interpretate this music file. With 200 bytes of Ram, you can make musics for PSG+FM+SCC.

Well : 8k of Ram - System Vars (0F380h) : 4992 bytes.

4992 - 200 bytes = 4702 bytes.

2k TEMP Ram. You can use this 2k temp ram for decompress and for ... the map in your game.

This is an example.

@Wolf: [Comparison with VCS and Coleco].

Sorry Wolf, but you can compare with GBA: 256k of slow ram, and 32k of high speed Ram. This is modern console. Do you can compare MSX1 with GBA?

SNES : 1 Mbit of Ram: 128k of Ram.

And you want use 64K of Ram in a MSX1?

Sorry, but is stupid. You can make "special" game using 64k ... tons of screens, play a "video", etc ... Sugar for the game. NO game.

But for make a "normal" good MSX1 game 8k or 16k. For make "demo game", yes, you need Ram. But MSX1 have tons of Roms, with real games. No "demo games".

Although in this modern times, "demo games" are aclamated, and real games are infravalored ... If the game have tons of colored gfx and tons of music is good game. The game is equal. Nobody play the game. If the game have real playability but no have tons of gfx, is bad game.

Yeah, you can see Golvellius. Only 8k of Ram. 12 x 12 screens + caves, etc ...

@Wolf: Well, 16kb was enough, was it? The only thing I'm saying is that with at least 32kb things will get easier for programmers and gamedesigners, which could raise the chance of succes.

Make GOOD game don't is easy. This is the problem. More people, "believe" that can make a game. Good games are for good coders and designers. If you are a real coder, o real designer for MSX system 16k is infinite Ram.