Quote:

Quote: Try to code games like Ghost'N'Goblins on MSX1 with the spectacular 4 sprite limit x scanline! I believe this is quite possible. You can limit the characters to 2 layers of sprites and still have them look good. That means you could have 2 characters on the same scanlines without flickering. A bit of flickering when another enemy or an attack is introduced would not make things that bad. In my opinion, the lack of hardware scrolling is more limiting than the number of sprites on the same scanline. For platformers, that is.

Hi,

Mmm, nice opinion, but two 2 layered sprites on a row isn't that much... Unless you don't want any action in the game. And think of the HUGE endbosses, not possible with sprites only!

As for the smoothscrolling, I guess one could get a nice colourfull 4pixel horizontal scroll by designing the 8x8 tiles correctly (i.e tiles that bound to the background should only have one colour to avoid colour clash in the uneven scroll position). To overcome the bandwith issue one could write an algorithm that detects 8x8 tile replication. I.e. if we don't use too much tiles, like 8, all 8 tiles can be replicated all over the screen. So only these 8 unique 8x8 tiles have to be transferred to video memory. Then the remaining 8x8 tiles in video mem can be used for softsprites. If one would use only 1 pattern+color table this just might be a cheap action. The score bar could be located in the second pattern+color table and could be displayed using a screensplit...

Damn, just need some time for it but I will try this...

Danny

personally I'd focus on the things an msx1 *can* officially do, rather than trick 'n hack around to mimic something it's not. The point about tricks on msx is: for each trick there's always a sneeky viper in the grass.. somewhere.
If scrolling isn't feasable, then focus on page-per-page. Even MSX2 games like Metal Gear, Usas, Vampire Killer do so, I don't see why msx1 games can't just do the ppp way..

Quote:

Mmm, nice opinion, but two 2 layered sprites on a row isn't that much... Unless you don't want any action in the game.

Yeah, I know it's not much, we'd get some flickering, but I think it would be possible to have the main character and other 2 or 3 enemies on the same scanlines (specially if the player flickers too), and it would not be so annoying. We are used to flickering.

Quote:

And think of the HUGE endbosses, not possible with sprites only!

Yeah, those should be done with the background. The areas where the bossfights take place could have a solid-color background. As most bosses do not go way up on the screen, the top part could even have some meaningful background, and the boss can freely move left-right in the middle section of the screen.

Quote:

As for the smoothscrolling, I guess one could get a nice colourfull 4pixel horizontal scroll by designing the 8x8 tiles correctly (i.e tiles that bound to the background should only have one colour to avoid colour clash in the uneven scroll position).

Yeah, this is a tough subject. 4 pixels using only one color is pretty noticeable, IMO. Smooth horizontal scrolling on the MSX is pretty much impossible, without visible glitches.

Quote:

To overcome the bandwith issue one could write an algorithm that detects 8x8 tile replication. I.e. if we don't use too much tiles, like 8, all 8 tiles can be replicated all over the screen. So only these 8 unique 8x8 tiles have to be transferred to video memory. Then the remaining 8x8 tiles in video mem can be used for softsprites. If one would use only 1 pattern+color table this just might be a cheap action. The score bar could be located in the second pattern+color table and could be displayed using a screensplit...

Now, this just sounds like a lot of trouble. Maybe an approach like that of Ghouls 'n Ghosts for the Amstrad CPC is the best: keep the "camera" static until the player gets close to the edge of the screen, when you quickly (1 tile per frame) scroll the view to show what's in front of the player. The screen just keeps scrolling in chunks, as the player gets closer to the edge.

I think that compromising the visual quality of the backgrounds is a high price to pay for slightly better scrolling. You just loose too many tiles, and a lot of detail, just to be able to scroll 4 pixels at a time.

Quote:

Damn, just need some time for it but I will try this...

I'd love to see that!

Quote:

personally I'd focus on the things an msx1 *can* officially do, rather than trick 'n hack around to mimic something it's not.

There's no fun in that. The fun part about coding for older systems is doing things that were not meant to be done with them.

Quote:

The point about tricks on msx is: for each trick there's always a sneeky viper in the grass.. somewhere.

But sometimes you can still gracefully avoid the viper...

Quote:

If scrolling isn't feasable, then focus on page-per-page.

I'd have to agree here. Either page-per-page or eventual quick-scrolls. Colorful smooth scrolling should be considered impossible for the MSX, though.

But I still think the MSX1 is capable of much more than people think.

Quote:

Colorful smooth scrolling should be considered impossible for the MSX, though.

Just wait for Malaika, hehehe

yes yes yes... I'm not saying it's impossible, but your 'trick' does have a hidden viper! You have really only 1 color per line, instead of 2. That's what I'm saying: *if* you use a trick, it'll come back at you in some way.. and in this case: reduced color options..

Quote:

You have really only 1 color per line, instead of 2...

You are right in this point: I get a new restriction (2 colors per 2 bytes instead of 2 colors per byte), but I get a smooth horizontal scroll in return... it is all about a balance of what you lose and what you get...

And about Wolf's formula (developmenttime = systemspecs^2). I'm not much agree with it: is it more dificult to make 16-color bitmap graphics with no restrictions than 16-color screen 2 graphics?. I don't think so , you know -and use to say- that screen 2 is for the big boys

BTW, nice demo!.

Quote:

Just wait for Malaika, hehehe

This game does seem very promissing. I really hope it is able to provide smooth horizontal scrolling of colorful backgrounds, I've been wanting to see that in the MSX for a while.

I have a hard time imagining how could the 1-color (per line) tiles on the edges of different colored blocks that meet look good. Did that make sense? It's a bit hard to phrase that! =)

I was thinking about making a smooth side scroller myself, but I'm almost giving that up.

Quote:

I have a hard time imagining how could the 1-color (per line) tiles on the edges of different colored blocks that meet look good. Did that make sense? It's a bit hard to phrase that! =)

The most important thing there is to know what tile will come next, so you must put a tile next to other that both have *at least* one of their 2 line-colors in common, in order not to get any glitch. It is tricky, but is not that hard. Is all about good map and tile planning.

Quote:

I was thinking about making a smooth side scroller myself, but I'm almost giving that up.

C'mon, give it another try, you can do it!

Quote:

(developmenttime = systemspecs^2). I'm not much agree with it: is it more dificult to make 16-color bitmap graphics with no restrictions than 16-color screen 2 graphics?.

I didn't say developmentdifficulty = systemspecs^2, did I?

I'm sure sc5 is easier, but is it faster? I'm sure G9k is easier, but is it faster? I think the mass of msxdev 04 05 06 games and the lack of G9k games (or even ordinary msx2 games, these years) proves my point a bit.. ^_^

Time and difficulty are two different things!

Quote:

Time and difficulty are two different things!

Well, usually you need more time to do difficult things than easy ones , but anyway, we're getting into an old #msx conversation

Mhoa dunno, the problem with rising specs is that you'll be planning bigger games and more gamefeatures, just because you have the technical opportunities to do so. And it's in a way logical to do so, as everyone expects those gamefeatures. I don't think ppl would be impressed with a typical shooter on a g9k (something that could've been done on MSX2 with just a bit better gfx, no we'd expect multilayers, multidirectional scrolls, huge sprites etc. It speaks that MSX1 games have less graphical options, and are thus done earlier. It's not for nothing that we made a shooter in 4 months. ^_^ *if* we'll ever do the same game on a g9k (really using g9k features), I expect FAR more development time, you can count on that!

MSX1 developers have more fun!

I always looked down on the MSX1 vpd specs. But now I'm developing (coding and gfx) for it for the very first time in many years and I'm totaly hooked too it now.
I don't know what it is (2 color limit dificulty, faster speeds than screen5 and up, 4 sprite limit, fixed pallete, easier to code) but I never had this fun before when creating something for MSX.

MSX1 rules!!

Perhaps Polka has a share in that fun? (without such a tool I wouldn't be doing msx1 games, as I'm not the type for photoshop & conversions)

Quote:

my development-formula still stands: developmenttime = systemspecs^2.

You're an optimist. I'd say: dev-time = 2^system-specs

Quote:

Perhaps Polka has a share in that fun? (without such a tool I wouldn't be doing msx1 games, as I'm not the type for photoshop & conversions)

Yup; until recently ;P
My tools are overtaking Polka! more and more. I really Enjoy Blitz plus. Wich is resulting in a complete new development environment for tiles, sprites, levels, bosses and animations.

But to be honest. Without Polka! I would never dared to develop something for MSX1.
So erh.........Thanks Wolf_