Genesis: Dawn of a new day

Impressive

thumbs up for the 'power up' like containers that will instantly kill you

Thanks for making it freely available. =)
From what I read/heard last weekend, I thought it was going to be cartridge-only.

Plus the speccy version scroll more smoothly, even if the spectrum cpu had to physically bit-blit (like in a true bitmap mode) every pixel. on msx i expect they use tiles. Teoretically, smoothness on msx should be better. the msx cpu have only to move +/- 512 bytes of data to scroll. The speccy one move about 4096 bytes every scroll.

Well said

I'mma gonna finish this one later today

If you like this game you should go for your way and just ignore our points
I think that as first (retro)-work the game is nice but the technical level of the game could be improved and the general look and feel is too much speccy for my taste
Actually the speccy version looks smoother and visually richer

Look better the rom is there

I don't think it's a bad game especially for a free one, but I also think most of your points are valid. MSX nerds like me and you have the tendency to nitpick and criticise. You have to be careful though and not overdo it if you suspect that the developer is getting demotivated by your reactions.

And keep things like "a crap spectrum port..." in your head, you stepped over the line there
(quote from Karoshi forum)

snout : try the J key (J like JUKEBOX !)

@hap: thx for pointing that out, agree with your points.

@Artrag: on MRC is forbidden any criticim. (Even if is and objective evidence, not a subjective one). So avoid similar posts and consider yourself lucky if you are not bannen for the life on ALL forums. OK?

We don't ban for being critical. We ban for trolling, abuse and generally messing up the good atmosphere we'd like. Only nagging and nitpicking here tends to set a negative mood here, which we don't like. You won't get banned for that, but also don't be surprised if people say something about it if you are constantly criticising

Just try to be a happy citizen here, that's all we're asking.

And like Manuel said, criticism is okay, but it's much more appreciated if you can bring it constructively. Do like the Americans do by saying "This could be better if you do X" or "You might look into doing X" in stead of "This sucks because it doesn't do X"

Thanks for all those posts.

I'm sure that MSX is more powerfull than a ZX and can do better thingies but Genesis MSX is a versión of a previus ZX game ZX and try to keep the esence even using some extra features. Really I think that we're talking about 'style' of making MSX programs like 'art'.

@huey: Ureal2 was programmed only for testing, not included in the final versions. Of course MSX did it better! by using a 2nd PSG. (like ROM cartridge version does).

Thanks MäSäXi!
PS: ops! Unreal2=>Second Reality tribute.

My words are clear. i complain about blocky animation not blocky sprites. the original sprites on spectrum are not blocky. the msx ones are ripped out so not blocky.
But is not acceptable that sprite animation is not blocky on a machine where the CPU MUST blit the entire sprite image on vram and is blocky on a machine where the cpu only should write 4 bytes x sprite. There is 1 order of magnitude of difference. And please do not tell about the slow vram access. In this situation really does not matter.

The same apply to tile-patterns

PingPong, like I said you won't be banned for this. Maybe your wordings were misunderstood because English isn't our native language.

Just try to keep in mind put on your happy face a bit more and try to voice your feedback a bit differently if you can.

Let's close this discussion now and move on to happy conversations again

Just another bit, as I do not want to seem a gooder
I think that coding this game for msx2 would have allowed a much simpler and better port from spectrum 128.
You could have
1) used multiple pages for double buffering (like the speccy 128 does)
2) displayed one single tile bank (s.c. hibrid mode) to reduce the cpu load
3) used up to 8 prerotated tiles banks to avoid any cpu work on background
4) used multicolor sprites and spend the saved cpu time to animate and move them in clever ways

...
5) SFX's kill the music. (but cartridge version sounds ok)

Hi, this is the game coder speaking . First I'd like to thank everyone for their comments, both good and criticism. I learn from them all.

Then, I find it a bit strange having to justify every single design decision I took in the game, but nonetheless I'd like to add some explanations. I'd like to start by saying that I never claimed that we had created the best possible shump in the MSX, or the best possible scrolling engine, or anything like that. We have created a game, had fun while doing it, and published it. That's it. From some comments it looks like it is some kind of heresy trying to port a game from the Spectrum and by a Spectrum coder... I'd say it's quite the opposite, I have learnt a lot about the MSX and enjoyed playing with it.

Anyway, let's start with the explanations.

It IS a Spectrum game port. Sorry about that, I did not mean to offend anyone.

here follow colors in nibbles 
step 0
AB|CD|EF...
step 1
BC|DE|F...
etc.

I explained it at the Karoshi forums: doing that would force a radical change in the tile and map design. First, the engine is designed for a 2 pixel scrolling, and the game runs at a 4 pixel scroll rate because my routines were not good enough to make it go as fast as it was needed. Second: I do not know of any way I could use that tile arrangement to avoid the usage of black in the tiles without only allowing specific permutations of tile + next tile. The engine allows any tile to be followed by any tile, and I did not want to change that.

This is being worked on. If testing is successful, you will have a no-jiggle version available by the end of this week.

That would be a hell lot of flickering. Just imagine you are in the same line with two laser shoots (2 sprites each laser shoot) and only one enemy. That would be 8 sprites in the same line, and of course we do not want the main ship to flicker (because it does not flicker, as you may have noticed). So we have 2 sprites available for 6 sprites in a line... too much flickering for me.

Had I done so, I could be criticized for not implementing a pixel-perfect collision system. The MSX one is not as perfect as the Spectrum one, where I could use some tricks, but I think it's acceptable after all the changes it went through.

Well, it looks like I got a few more points after all. About the "extra effort", I can only say we have different perceptions of the amount of effort required to do that. Seriously, I am happy to discuss all technical details about the game and how I could have done it better, but I find that claim offensive. We have spent an awful lot of time developing this game, and every decision has a meaning (or is just a mistake from my side), it's never because of laziness. I will probably never be as much a good MSX coder as you are, but you know little to nothing about the inner details of the game, so saying a "reduced extra effort" is too much.

About the MSX2 idea: yes, everything could have been better on MSX2. But the game was conceived to be released on a MSXDev (now it's out due to the no-megaROM restriction), and I still had to learn a lot about the MSX before I could consider trying something on the MSX2. After all, the fun is in working around restrictions, isn't it?

No, I can confirm it is not like that, and you will be able to check it yourself as soon as I have cleaned up the code mess and released it. BTW, you could have also seen it if you had run the game in Meisei.

Does it change your perception about the game? I guess not, but here are the gory details anyway:

The scrolling engine works on two subsets of 128 tiles, to avoid flickering. It allows up to 32 tiles, each 24x8 pixels (let's call each char X-Y-Z). To build a new frame, we have 64 tiles that are fixed and precalculated (the mixed tiles X-Y and Y-Z at the given pixel shift). Those 64 new tiles are transferred to VRAM as such, while the name table is being built. Since each tile can be succeeded by any other tile, we have 32x32=1024 possible combinations, too much to be precalculated: 1024 combinations, 48 bytes each, 4 possible shifts... just make up the numbers, and they would have to be in RAM because there are 7 levels, so having every possible combination precalc'ed is just not feasible.

So, for the remaining (up to) 64 tiles, we have to create them dynamically, combining each Z char with the X char after it, checking whether we have already combined them to avoid duplicates, and then transfer them to VRAM. Probably a better caching algorithm could have helped here, at the expense of a non-constant framerate.

Finally, when the 128 tiles have been transferred to VRAM and the updated name table is ready, it is copied to VRAM at the beginning of the interrupt.

Is it the best design for MSX? Absolutely not. Is it the one I wanted to try out? Yes. But please, do not guess the level of effort put in this game. I did not do it any better because, with my current level of knowledge, I cannot do it any better.

PingPong, do not worry, I have nothing against you. I think everybody must have possibility to critizise things here, as long as they don´t do it in a nasty manner.

Metalbrain, thank you for pointing me out those things about Joffa. I didn´t know he is not among us anymore. Do you know the name of his unfinished game and is there any screenshots to be seen anywhere?

? ? ? I didn´t find anything annoying when playing using music+sfx at the same time.

Personally, I feel it´s a pity there is not a chance to select between music+sfx/only music/only sfx/silence in cartridge version. It is programmers´ own decision to decide what to keep in their own game, and I just can tell my own feelings, I mean that apart from few first european MSX games, there are not many MSX games which allow to select whether to play music and/or sfx or completely silence instead. I must confess that chance to alter music volume in Mutant Monty is luxyry in my opinion!! I am talking about the fact that most "game customising" almost in any MSX game is that you can either press fire/space to start to play game or not to play at all. But I guess you wanted to decide between making better sounding music or sound selection and of course I appreciate ********A LOT******** the chance to hear TWO PSG music on my MSX someday in near future!!! (Yes, I want to buy your genesis cartridge!!!!)

I didn´t see anything wrong with gun turrets and background. Yes, as someone mentioned it, I started to look at it while playing and found out that gun turrets are *very slightly* not synchronized with the background, but it was almost non-existent, I really didn´t find any problem from that.

Isn´t it already? On bluemsx there have been several cases, where enemy shot went through the upper pixels of the body of my ship and I did not explode. That´s fine for me, no problem.

A BIG thank you everyone who participated in making this game!!!!

I've read about your algorithm. It's quite complex and time consuming. Personally i ill try a similar thing only on a more powerful cpu, not with a z80 @3Mhz. (TurboR ?)
I suspect also that the time you use to perform your dynamic tile generation is greater than the time to do a full bitmap copy. The speccy version does not do this and is more faster. Pratically, if i've understood correctly you are moving 128*8 tiles+512 nametable => 1536 bytes every frame buildup.+ the time you use to understand what tiles you need to generate.
Have you profiled the time used for your routine? Maybe you can switch to a full monocrome gfx and blit 4096 bytes every frame. Maybe the difference is not so high.

It was called Saucer, there's a very early version available, and also some code:
http://www.worldofspectrum.org/infoseekid.cgi?id=0025291

There were some plans of releasing the game after he passed away, supposedly it was finished by an old Ocean mate, and only needed some artwork (to be done by a famous artist who used to do many Ocean covers back in the day), and the loading screen based on that artwork (to be done by another ex-Ocean graphician), but it's been a long time since the last news about it.

Metalbrain, can you please send email to me? I have some questions (other than above) for you.

Just tested the lag free version
Much better now! Excellent !!

what have you changed since this morning?

@Huey. Thanks for your comment regarding the music. Tracker and player was programmed by Retroworks crew and still in development. Both are for free use.

@utopian, so the 4 pixel scroll is because of timing?
Run the game in the interrupt and the scroller asyncronous outside the interrupt, then you can go 1 pixel scroll!
Don't go 2 pixels, especially with fps issues need 1 pixel, because sometimes things jump 3 pixels.

If you can pull that stunt, you win the best scroller award.
In the category "more than 32 chars gfx and game actually released".
The horizontal scroll award is still held by Circus Charlie, no?

p.s. the irony is that with 8x8 scroll you would have got less bitching.
It is heartbreaking to see all the infrastructure for scroll, and then it is fixed to 4 pixels.
Fixed timing, big pity when you already got doublebuffering to be free of hitting the beam.

To everyone who starts thinking of how the background workload is to be split, make it asynchronous outside the interrupt. The interrupt be splitting the workload automatic.

Just a bit syncronisation to do:

async background code:

;this one is more like after rendering work was done
DI
load "VDPR2" variable for interrupt doing the nametable register change.
give interrupt code a pointer to a sprite move job for things glued to background, no more wobble
EI
HALT
;at this point interrupt has loaded VDPR2 to VDP register.

;begining of async work
DI
load games level scroll position which is updated by interrupt. never game slowdown, only fps slowdown.
EI
flip my doublebuffer variables, "show" versus "render"
draw the stuff

_____________________
interrupt code:

load VDP nametable register from VDPR2 variable
run background glued sprite moves
dump all to SAT. the normal sprites have been prepared in previos frame. i.e. in stuff following below.

;beam better not reach visible area before this. if it does, SAT dump at VDP speed limit

move level scroll position
move the normal sprites, making the result for SAT dump in next interrupt.

RET

I've just released a scrolling demo using two pages and two tileset and it looks good
the cpu has only to update the pnt and swap tilesets at each 4 pixel step
I need to cope with sprite cloning now...
http://www.msx.org/forum/development/msx-development/nametab...
Look for the nemesis iii dsk

I've found it !
You can select the level of the game by pressing some key before pressing the x key, then the spacebar.
Hint : there are 7 levels !

I have seen the Spectrum version as well, and I am in awe.

Great ! Maybe this could inspire the birth of Genesis II, who knows
Going to take a peek.

Very generous to provide the sources.

I hope it may one day trigger someone to start coding.