Alex Kidd Port

[Dexter]

Oh, I saw this a few minutes ago. The F18A version looks sooooo beautiful!

[TheMole]

Warning, don't have your sound too loud for this one, there's a small bug that I haven't fixed witch garbles the sounds when Alex dies.

 

I added the overworld screen back again, this time around with room for your score, life and amount of money. It was interesting, but I'm actually using the same screen in 9918a mode and F18A mode. The only difference with the F18A is a slightly tweaked, more vibrant palette. There just wasn't much reason to create a separate F18A version as I thought the 9918a version looks very good as-is.

I also fixed the moonwalking sprites in ECM3 mode. I'm close to the point where I think it can be released for playtesting. We'll see how long it takes, but I'm hopeful .

 

[+Schmitzi]

WOW, really amazing

[kl99]

AMAZING!!!! TOP Graphics!

Is the engine or your game using the GPU in any kind?

This really shows the potential of the F18a

Klaus

[+OLD CS1]

I am willing to bet the bug is in your sound lists, not muting all of the unused channels when playing the death music.

 

Any chance we can see how the 9918 version looks?

[RXB]

That is truly impressive!

[TheMole]

I am willing to bet the bug is in your sound lists, not muting all of the unused channels when playing the death music.

Something like that. The sound lists indeed don't mute the unused channels, but the idea with Tursi's player is to do this in code. When including his library I only took the assembly parts, and not his C functions which include a MUTE_ALL command. It's been on my todo list for the longest time, and I'll definitely add it before I post the playable demo.

 

Any chance we can see how the 9918 version looks?

Definitely, I don't want to create the impression that I'm leaving the good ol' 9918 behind with this. It's still very much a first class citizen in this game and everything I add gets added for the 9918 first.

 

[Iwantgames:)]

Wow! This looks freaking sweet!!! Great work

[TheMole]

Finally some more progress on this. I got stuck on a bug that slowed me down for quite a bit over the past two weeks, and it turned out to be something really stupid in a totally unrelated part of the code from where I was looking all this time.

 

Anyway, very close to a public demo now:

• Alex now turns into an angel when he dies
• Added a "story" screen to certain levels. In this clip it's just the first level, but these will be sprinkled in between certain levels to progress the story in the final game.
• Added a "game over" screen when you die
• Fixed the annoying sound garbage issues

The sound that Alex makes when he dies is still wrong, but I'm having some issues getting vgmcomp up and running to create the replacement sound. Once that's resolved you should hear the same sound as in the original game.

I also need to add a couple of extra screen transition effects (e.g. like the "wipe" effect on the title screen) here and there, but that's very minor.

Finally, this is a video of the 9918a version, but the added screens work and look nearly identical in the F18A version (just with slightly more vibrant colors).

 

Apologies for the crappy video, I tried a different capture and upload method in hopes of improving the quality, but it's worse than before :-/.

 

Edited September 26, 2015 by TheMole

[TheMole]

AMAZING!!!! TOP Graphics!

Is the engine or your game using the GPU in any kind?

This really shows the potential of the F18a

Klaus

 

Nope, just two 3bpp tile layers and 3bpp sprites. I might do a wavy underwater type effect with the GPU in certain levels later one, but that's not for now .

[Iwantgames:)]

Looks awesome can't wait to play this one

[TheMole]

So... my main development machine, a 2012 Mac Mini, just crapped out on me (I believe it's the power supply). Luckily, the game's source code is in my Dropbox folder, so I haven't lost that. Unfortunately however, I can't access any of my PC-side tools until this is fixed or I can transfer the contents of the HD to another machine (which is a major pain in the ass with Mac hardware... )

 

Takes this as a heads-up that it might be a week or two before I'm back in full development mode...

[Iwantgames:)]

Oh man that sux always hate when one of my machines craps out

[+OLD CS1]

PPC or Intel MacMini? Are you going to try to fix it?

[RXB]

2012 Mac Mini would have to be a Intel Mac as 2009 is when Apple switched to Intel from PPC.

[TheMole]

Rich is right, it's an Intel i5 based machine. I am going to try and have it fixed, I have an appointment at the Genius Bar tomorrow. If it really is the power supply, it should not be too expensive.

 

I have to be in the States in a couple of weeks though, so I think I'll be picking up a new one anyways (it's roughly 20% more expensive to buy Apple gear here in Europe). I can always use the old one as an HTPC.

[RupanIII]

Can someone point me to resources which tell me how popular and in use the F18a FPGA and or the V99x3 are on the TI-99/4A ??

 

 

I plan to make one version that detects and supports both chips. I was thinking about doing something for the v99x3 as well, but I don't know how feasible it is.

[TheMole]

Can someone point me to resources which tell me how popular and in use the F18a FPGA and or the V99x3 are on the TI-99/4A ??

 

That's hard to gauge, but at least on this forum, 50% of users seem to have an F18A, 36% only have the classic 9918a and 14% have a v99x8. This is according to a poll by Omega to which something close to 40 users responded: http://atariage.com/forums/topic/238677-breakdown-of-real-iron-users-primary-configurations-2015/?hl=%2Bvdp+%2Bpoll&do=findComment&comment=3244022

[+OLD CS1]

2012 Mac Mini would have to be a Intel Mac as 2009 is when Apple switched to Intel from PPC.

 

Ah, I missed the "2012" part. Would not have asked, otherwise.

[TheMole]

Small progress update...

 

I've been prepping the release of the demo, and as part of that I wanted to run the game in other emulators to test compatibility. Everything seems to work fine in MESS, but there's an inordinate amount of screen tearing going on, which I was pretty sure would happen on real iron as well. So I reckoned the game was running too slowly, which meant I had to first confirm this and second figure out how I can optimize it. Luckily MESS has a very accurate raster-based VDP implementation, which means I can use strategically placed background color changes to time the different parts of the game. This is what it looks like when standing still (ie, not scrolling, not punching, not jumping) and without enemies on the screen.

 

The color coding is as follows:

• White: copying the sprite attribute table to the VDP (128 bytes). There are two version here, odd and even frames, for the sprite flickering routine. The odd frame displayed here takes significantly longer (even frames do not register as a full scanline).
• Magenta: scrolling routine: nearly none existent when standing still.
• Cyan: Input and player state machine routines.
• Green: calculate enemy positions and movements
• Light Yellow: sprite-sprite collision detection
• Dark Yellow: sprite-world collision detection
• Light Red: post-collision detection player movement routines
• Dark Red: player sprite rendering (to RAM buffer)
• Light Blue: enemy sprite rendering (to RAM buffer)
• Dark Blue: block debris animation routines
• Black: wait for vsync (and play music and sound effects)

 

Now, when scrolling at full speed, jumping and with enemies on the screen (worst case scenario), the result is this:

 

As you can see we're rolling over into the next frame (remember the black part at the top of the screen is the handling of the sound routines, which should've happened in the previous frame while waiting for vblank). Clearly the scrolling itself takes a big chunk out of our overall budget at roughly 30% of the available cycles (although we seem to have lost the blue sections, so MESS might not show the entire vblank area), but collision detection and to a lesser extent sound playback and enemy calculations are not insignificant either. This is frustrating because it means that there's not one specific area to focus on.

 

For the scrolling, I need to consider that at maximum speed Alex runs two pixels per 1/60th of a second. That means that worst case scenario I am trying to push 192 bytes to the VDP per frame for the scrolling alone (add another 128 bytes for the sprite attribute table). I think that theoretically this can be done in under 3000 cycles, but 30% would indicate I'm using approximately 3900 cycles. I should be able to do a bit better.

 

If I can optimize the scrolling to be close to those theoretical 3000 cycles, I can look at some of these other routines, but it looks like I'm about 1600 cycles too slow in the screenshot (and there's no saying it doesn't peak higher). Even if I can get the scrolling close to the theoretical case, I still need to find 700 cycles in a couple of routines that all together consume about 3300 cycles. I'm not very hopeful I'll be able to maintain 60fps on the standard 9918a. I wonder if a 30fps version would be seen as a big sacrifice?

 

Other than this one (major) issue, I think I'm almost ready to release. I've added a new level, fine-tuned the collision detection with enemies, fixed some long outstanding bugs, cleaned up all screen transitions, ... so close...

 

 

[+Ksarul]

I'd try the downshift to 30fps, just to see how much of a difference it makes--it may work, and it allows you to concentrate on finishing it, instead of fighting to make it work as expected at 60fps.

[Asmusr]

Cool to use the background color for timing measures, I usually use the debugger in Classic99. I calculate with having 50000 cycles at 60Hz so I don't understand why 3900 cycles would be 30%?

[sometimes99er]

Looks good.

 

Luckily MESS has a very accurate raster-based VDP implementation, which means I can use strategically placed background color changes to time the different parts of the game.

 

Excellent. This will come in handy.

 

[TheMole]

I calculate with having 50000 cycles at 60Hz so I don't understand why 3900 cycles would be 30%?

 

You're right, I got confused and used the roughly 12000 cycles we have during vblank as the total per frame but I'm double buffering (not very well, mind you, but that's another story) so I can draw to VRAM for the entire frame. That seems to imply I'm using way more cycles for scrolling (about 15000?) than I think I should be if I'm not mistaken about what the most efficient implementation would look like (that '3000' figure seems awfully far off now...). Back to the drawing board to figure out how much potential for optimization there is, hopefully I was completely wrong in a good way .

[TheMole]

Cool to use the background color for timing measures, I usually use the debugger in Classic99.

 

Excellent. This will come in handy.

 

I don't remember where I first saw this trick, but it's especially handy when not working in assembly directly. The pain of figuring out which code gcc has output to do accurate cycle counting is something best reserved for very special occasions , so this is a decent alternative to get a rough idea on where the biggest optimization opportunities are.