msxdev-karoshi surprising again! :)

[nitrofurano]

otherwise, perhaps coding titles specifically for your distribution process, totally independent of the contest registering process, might be a bit different - but for me is crucially important that the sources of the game can be released too - for me it is way more important to show to a wider range of people how possible and simple can be coding games for ColecoVision, and having more and more people making ColecoVision still alive, than to profit some pennies from some games, and contributing far less to the development community - and it is also important that the collectors need to have a clear notion that, when they are acquiring these burnt roms socketed into cartridges, they are helping, and being part of this process, more than merely "buying" a game - and perhaps these people can even get encouraged to try to code their own ColecoVision games if they want - this is the very most important thing i consider and care when i try to code games for ColecoVision

[BrianBeuken]

msx-uridium-cv-dk.png

I'm 100% for a ColecoVision version of MSX Uridium.

 

 

How would you handle the scrolling on CV since the TI chip does not support any kind of native scrolling?

Edited June 18, 2014 by BrianBeuken

[ten-four]

It can be done with the right technique.

 

Just check the code in our ColecoVision Nova Blast, that will be the closest.

[nitrofurano]

How would you handle the scrolling on CV since the TI chip does not support any kind of native scrolling?

take a look at Konami’s Circus Charlie for MSX1 (and their conversions to ColecoVision and SG1000) - it’s exactly the same technique, or very similar

[+nanochess]

How would you handle the scrolling on CV since the TI chip does not support any kind of native scrolling?

 

There are several possible techniques:

 

• Arrange patterns in a way that you do scroll simply redefining bitmaps (typically used for small zones)
• Predefine bitmaps and only update patterns (typically used for full screens, I use this in Princess Quest and Mecha-8, you can search Youtube videos)
• Predefine bitmaps, update patterns and some bitmaps on the way (also for full screens, very complex)

[BrianBeuken]

hmmm yes very nicely done on vertical or horz scroll, but none of those techniques would allow for a true smooth 50hz 8 way scroll unless the graphics were incredibly simplified. Writing extensive bitmaps is extremely time costly and that's the principle needed to get uridium and other 8 way scrollys to work... does the SGM provide scrolling?

[Kiwi]

All of these entries are awesome. They encourage me to continue working on my current projects.

Burn Rubber I know that does multiple directional smooth scrolling I think using tiles.

Scrolling in 50/60 hz is pretty difficult. Replacing screen tiles for me is the quickest since the name table is 784 bytes. So 200-300 byte writes to vpd, so it'll complete updating the screen within 3 frames.

[+nanochess]

hmmm yes very nicely done on vertical or horz scroll, but none of those techniques would allow for a true smooth 50hz 8 way scroll unless the graphics were incredibly simplified. Writing extensive bitmaps is extremely time costly and that's the principle needed to get uridium and other 8 way scrollys to work... does the SGM provide scrolling?

 

The Super Game Module only provides 32K RAM and an AY-3-8910 for sound.

[Pixelboy]

The Super Game Module only provides 32K RAM and an AY-3-8910 for sound.

Which can be useful for setting up graphic buffers which can be blasted into VRAM whenever ready. It doesn't really add anything concrete in terms of graphic capabilities, but a good programmer can use such a RAM buffer to do nice things that wouldn't be possible with just 1K of RAM.

[artrag]

In "bitmap" mode tms9918a offers 3 banks of 256 tiles each

Uridium relies on undocumented features of the vdp that, for two banks, allows to show two pages with 256 tiles each

In this way you can show 512 per bank (1024 in total).

The trick would work perfectly on Colecovision and on TI/99A

The extra ram is needed to expand level data, and game logic, nothing to do with the scrolling which is perfectly doable

[BrianBeuken]

All of these entries are awesome. They encourage me to continue working on my current projects.

 

Burn Rubber I know that does multiple directional smooth scrolling I think using tiles.

 

Scrolling in 50/60 hz is pretty difficult. Replacing screen tiles for me is the quickest since the name table is 784 bytes. So 200-300 byte writes to vpd, so it'll complete updating the screen within 3 frames.

 

I assume you are only writing to the VDP during the vblank refresh then?

that's a good example of 8 ways scroll but yes it highlights how simple the graphics need to be so you're not redefining hundreds of chars.

[BrianBeuken]

In "bitmap" mode tms9918a offers 3 banks of 256 tiles each

Uridium relies on undocumented features of the vdp that, for two banks, allows to show two pages with 256 tiles each

In this way you can show 512 per bank (1024 in total).

The trick would work perfectly on Colecovision and on TI/99A

The extra ram is needed to expand level data, and game logic, nothing to do with the scrolling which is perfectly doable

ok but all this really allows you to do is create a (near) screen size character map that you can dump a bitmap to? I assume scrolling is then done by dumping to via x and y offsets into that buffer....but that's going to require a massive RAM buffer that's not available on the standard CV..hmmm

 

So what are these undocumented features?

[artrag]

not a single tile definition is updated while scrolling: all "rotated" tiles are already preloaded in vram (as said we use 1024 tiles)

one step of scroll costs only 256+256 bytes to be updated in the pnt

[+nanochess]

not a single tile definition is updated while scrolling: all "rotated" tiles are already preloaded in vram (as said we use 1024 tiles)

one step of scroll costs only 256+256 bytes to be updated in the pnt

 

Same in Princess Quest, all tiles predefined with automatic tools and I update 640 bytes each two frames.

[Maggoo]

And voila, Colecovision version is playable, although silently for now:

 

[artrag]

 

Personally I dislike this in the 2012/2013/2014 year rules, because the contest explicitly trying to "control" my distribution rights.

 

For example, when I published Zombie Near, obviously it "stays" within the contest archives. For cartridge publication I was being lazy, but publisher (Matra) asked me for an enhanced version and they were right, specially in MSX scene, if people thinks it's same they simply download the ROM and don't buy the game...

 

So if you publish a game in the MSXdev under these new rules, it limits indirectly the publication of homebrew cartridges for MSX.

 

I've commented about this before http://karoshi.auic.es/index.php/topic,2281.0.html without official response from organizer, only the previous contest maintainer said it shouldn't be read strictly.

 

Anyway it was enough to keep me away from the contest.

 

The rule is quite dumb (and even not clear to me), anyway it can be easily be skipped.

Nothing prevents you do a deluxe edition and publish that on physical cart outside the contest.

We are doing exactly this, working of a 64K deluxe edition with additional features to be released on cart, leaving the 48K rom to the contest

 

http://www.trilobyte-msx.com/uridium/

 

IIRC anyway you did something similar with mecha 8, didn't you ?

Edited June 19, 2014 by artrag

[nitrofurano]

the only part of the rule, in my opinion, that i considered not clear enough, was about when can or should we release the sources of the game - Viejo Archivero said to me that is better to release in the end of the bug fix period (this sunday night), so i will do (and this was my very first motivation to participate in this contest, to show how useful Boriel’s ZX-Basic can be for coding games for MSX1, and how simply can we target to similar platforms like ColecoVision and SG1000, and to motivate all people, like here, about how simple and possible for newbies can be coding games to MSX1, ColecoVision and SG1000)

 

about the rule, one that he found unclear as well is that related to what is to be considered as bug fix in the bug fix period (that was related to my CMJN entry, that can be considered "minimally playable", and i will try to not "abuse" this situation on improving the game that much - perhaps i will only do some bugfixes and code cleaning, and leave it as "crappy" as it is now )

 

it seems that the rules are open for discussion and improvement, by suggestions - i guess that anyone is welcome to help discussing that there - but i really believe that the resulting roms has to be always available for unrestricted download always (i imagine that the "burnt and socketed" publishing/distribution initiatives has to seriously consider and count with this situation)

Edited June 19, 2014 by nitrofurano

[BrianBeuken]

not a single tile definition is updated while scrolling: all "rotated" tiles are already preloaded in vram (as said we use 1024 tiles)

one step of scroll costs only 256+256 bytes to be updated in the pnt

I just checked the uridum video and yes I do understand this concept for horizontal scrolling which is relatively simple but eats ROM (there's always a compromise(

I'm really looking to find a way to do smooth 8 way scroll, all the examples quoted show only a vert or horizontal system, apart from the Burning rubber game which makes a damn good attempt at 8 way using simplified graphics to allow for reduction of work.

 

Back in my Spectrum/Amstrad days we just used to dump recalculated screens to the visible screen but that's not practical on a low RAM, char map based screen.......creates an interesting and difficult proble

Edited June 19, 2014 by BrianBeuken

[artrag]

Having 1024 tiles you can use the very same technique (precomputed tiles) but you have to accept a simpler graphic. This, only if you want to be able to plot the screen at any position by simply moving 512 bytes ( 60 frames/sec).

 

If you can accept lower framerates, you can use the two pages for double buffering the whole map definition, that in my special half mode is 6 Kbytes. You can take the time you like to do that, and the scroll will be fluid, because you show one page and work on the other.

 

In this case obviously, assuming about 1500bytes/frame at 60Hz, the framerate will be low, about 15 frames/sec.

[+nanochess]

 

The rule is quite dumb (and even not clear to me), anyway it can be easily be skipped.

Nothing prevents you do a deluxe edition and publish that on physical cart outside the contest.

We are doing exactly this, working of a 64K deluxe edition with additional features to be released on cart, leaving the 48K rom to the contest

 

http://www.trilobyte-msx.com/uridium/

 

IIRC anyway you did something similar with mecha 8, didn't you ?

 

Yep, but the rules of MSXdev'11 were far more friendly and well specified http://msxdev.msxblue.com/?page_id=413

 

In fact as I published the enhanced Mecha-8 cartridge without making ROM available I got some angry letters , I think (well, maybe overthinking) that the new rule since MSXdev'12 was because of that.

 

the only part of the rule, in my opinion, that i considered not clear enough, was about when can or should we release the sources of the game - Viejo Archivero said to me that is better to release in the end of the bug fix period (this sunday night), so i will do (and this was my very first motivation to participate in this contest, to show how useful Boriel’s ZX-Basic can be for coding games for MSX1, and how simply can we target to similar platforms like ColecoVision and SG1000, and to motivate all people, like here, about how simple and possible for newbies can be coding games to MSX1, ColecoVision and SG1000)

 

about the rule, one that he found unclear as well is that related to what is to be considered as bug fix in the bug fix period (that was related to my CMJN entry, that can be considered "minimally playable", and i will try to not "abuse" this situation on improving the game that much - perhaps i will only do some bugfixes and code cleaning, and leave it as "crappy" as it is now )

 

it seems that the rules are open for discussion and improvement, by suggestions - i guess that anyone is welcome to help discussing that there - but i really believe that the resulting roms has to be always available for unrestricted download always (i imagine that the "burnt and socketed" publishing/distribution initiatives has to seriously consider and count with this situation)

 

The rules say "Publishing the source code of the games is not compulsory, but it is strongly encouraged." that means that you can publish the source code if YOU WANT, but you're not required to do it.

 

In fact it was ran a poll for this, check it http://karoshi.auic.es/index.php/topic,2390.0.html

 

The bug fix period is for doing enhancements or solving bugs you found in your code after sending it to contest. It can happen if you're too pressed with deadline.

 

And finally I want to clarify that I agree completely that the ROM files sent to contest should be always available for unrestricted download.

 

Final note: include at least a manual in text format with your entries, or otherwise your entries are going to be disqualified.

[artrag]

 

Yep, but the rules of MSXdev'11 were far more friendly and well specified http://msxdev.msxblue.com/?page_id=413

 

In fact as I published the enhanced Mecha-8 cartridge without making ROM available I got some angry letters , I think (well, maybe overthinking) that the new rule since MSXdev'12 was because of that.

 

 

The rules say "Publishing the source code of the games is not compulsory, but it is strongly encouraged." that means that you can publish the source code if YOU WANT, but you're not required to do it.

 

In fact it was ran a poll for this, check it http://karoshi.auic.es/index.php/topic,2390.0.html

 

The bug fix period is for doing enhancements or solving bugs you found in your code after sending it to contest. It can happen if you're too pressed with deadline.

 

And finally I want to clarify that I agree completely that the ROM files sent to contest should be always available for unrestricted download.

 

Final note: include at least a manual in text format with your entries, or otherwise your entries are going to be disqualified.

 

Well, I will publish the file rom of deluxe edition only in one or two years (once the commercial life of the cart has expired)

About sources, I could release them only for the msxdev edition, but actually without matlab there is little chance anyone will be able to reuse them.

 

Why do you say the manual has to be text ? We added nice pdfs.

[+nanochess]

 

Well, I will publish the file rom of deluxe edition only in one or two years (once the commercial life of the cart has expired)

About sources, I could release them only for the msxdev edition, but actually without matlab there is little chance anyone will be able to reuse them.

 

Why do you say the manual has to be text ? We added nice pdfs.

 

It was for Nitrofurano, his entries doesn't include manuals .

 

I've always included nice PDF manuals and high-resolution JPG labels for cartridges in my entries

 

Myself I think I'll publish ROM files once the publishers get cartridges sold out and for historical purposes, but still my games are too recent.

[nitrofurano]

thanks a lot for reminding, @nanochess! - from my entries, the msx version has a readme.txt and a todo.txt files! i’ really lazy on doing layout design for manuals in pdf, for now! (and the labels are still for msx cartridges only, in 150dpi! )

Edited June 22, 2014 by nitrofurano