This game can be played also in a version for Genesis. The automation could get it most of the way there though with optimizations afterward.If the game emulation is slow, try to speed it up by reloading this page without ads or choose another emulator from this table. Any inefficiencies would result in some significant slowdown. If there was a way to do it on the SMS automatically, there would likely be inefficiencies in the same way, except the processors are pretty similar in speed at the clock rates the 2 consoles run at. If the automated process resulted in some inefficient code, it doesn't really matter unless it's REALLY bad, because the speed difference is more than enough to make up for any inefficiencies and keep the game running at full speed. Not quite 4.2 times as fast as the clock speeds suggest, since the 6502 is apparently more efficient per clock cycle, but let's say 2-3 times easily, if not more. But keep in mind that a Motorola 68000 running at 7.6mHz as the Genesis does is going to be considerably faster than the 6502 running at 1.79mHz in the NES. ![]() I've read about that Genesis port, and apparently a lot of it was automated. ![]() The actual source code for SMB has been floating around for a few years. I would be curious to know if a similar program could be developed to convert the SMB NES code to SMS compatible code. I think the person that did that mostly automated it since SMB was a rather simplistic game. I've always wondered if porting Super Mario Bros to the SMS could be done as smoothly as it was for the Genesis. Putting NES games on the MSX is a different (off-topic) story lol. The skill of the programmer plays a role for sure but it's not impossible to do. When you mention, "sprites" are you refering to the 8x8 tiles making up the player, or the frames of animation for the player?Īlso, there's plenty of examples of Master System games with very smooth animations and lots of sprites on screen without flickering or looking ugly. Have to be careful if you have scrolling and have to update columns or rows of tiles due to the scrolling, as It can be visible to the player. although, if you have many tiles/sprites to update each frame, a) you can alternate the updates, b) you can use unsafe updates in vblank time for some updates and safe for others, it is a timing question. I was interested in this topic due to the last project, in which I am loading the player sprites at real time (like in ninja gaiden, by example, doing this I am using only about 40 sprites at once for the player, the player weapons, the power capsules, the explosions.) which is a good thing, as you get more free sprite slots for the enemies. I'm trying to hit a sweet spot where the graphics take advantage of the Master System's better hardware, but it still feels like the NES version. The sprites and other various graphical differences are too extreme for my goal in making a relatively similar version to the original. Even though it's also on a Z80 system, I'm not looking at it for code at all. On the one hand, FM synth music on the other hand, everything else lol. The MSX port is definitely a pretty mixed bag in terms of quality. I guess it was excusable on the NES since that only had 8KB RAM and a lot of that space went to general RAM expansion, but when you have 720k to work with.) (it was a floppy disk game, and perhaps even more annoying is that it wanted a whole 720KB disk to save, and it could STILL only save one file. I only remember playing a bit into it and stopping because the loading time was kind of annoying. (I wouldn't expect it to have great use of the extra colors, it did seem to be a kind of careless port.) ![]() ![]() Final Fantasy 1 did get a MSX2 port which used 16-color enemies.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |