TheMole

I simply render the sprites in a CPU buffer in the order they appear in. When uploading to the VDP, I check the vblank interrupt counter. If it's odd, I upload in ascending order, if it's even I upload in descending order. Works pretty well, and there's only one check per frame instead of one per sprite.

And I'd love to see what you came up with!

I don't think so, unless XB 2.7 does not feed lines in from the bottom of the screen when printing? Isn't the cursor always on line 24 in these things? Maybe the upper two are cut though .

We are of course completely ignoring the quality of the random number generator in these comparisons, but I did a rough comparison with a full GCC implementation as well (meaning I used a C-only random number generator instead of using an assembler library or implementation, that might speed it up even further). Also, I did not inline the function (which would take out any time spent on the function call itself) since the other language tests have included that as well. Simply adding "inline" to the function definition would speed this up even more, at the cost of using more memory each place the function is used in real code. // 16-bit random number generator. // Based on George Marsaglia's xorshift algorithm unsigned int rnd_xorshift() { static unsigned int x = 1, y = 1; unsigned int t = ( x^( x<<5 ) ); x = y; return y = ( y^( y>>1) )^( t^( t>>3 ) ); } // Simplified version of main function, skipping all screen setup stuff void main_loop() { putstring(" Working... "); for (loop = 0; loop < 65000; loop++) { x = rnd_xorshift(); } putstring(" Done!\n"); } Using the stopwatch, 65000 loops are done in 6.064 seconds (I averaged 10 runs to try to minimize the error margin of doing this manually), which means around 0.09ms per loop, or three times faster than fbForth and ten times faster than compiled Basic. Apparently the quality of the algorithm itself is pretty good as well, but of course, it's an integer algorithm and it only does two bytes here. Having said that, I am sure that versus the Basics, C wins a lot on the for loop itself already. So all-in-all not a fair test of the speed of the RND algorithm as such, but a good indication of how performance would differ in real world applications.

I'd like to do this from C to add another data point to the comparison, but I want to make sure I use a comparable random function (as in, with comparable target type and size). What does TurboForth use for this?

I wouldn't be able to have the black 1 pixel wide outline around the base, which I think kinda defines the style of the rest of the graphics here.

Yeah, but I think the volcano is too big for the more realistic shape, hence why I tried it with a smaller version and an extra forest. Thanks for the inspiration though

What about this?

Uhm... thanks, I guess .

Huh, that doesn't look half bad... it might work better with a square-based volcano though. Would you mind trying your hand at a modified version if I send that to you (or post it here)?

Hmmm, I gave that a try and to be honest, I'm not entirely convinced. I did change the green background color to the middle green instead of the light green to give it less of a pastel look, so I used the light green for the "highlights" which looks a bit much, to be honest. I'm thinking of doing the opposite and adding some shadowing using black pixels to make it look a bit more organic. It's hard to see in the png, but the edges are actually "dark" yellow where the rest of the scroll is light yellow, so I did keep the edges. I replaced it with light red, which is much more obvious but it actually looks pretty nice. I think I'm going to keep it like that, thanks for the input!

I've been working on the graphics for the "map" screen that is shown in between levels and when Alex accesses his inventory. It doesn't do much except show where on the world the current level is by means of a bouncing arrow, but I still think it's important to add stuff like this to make the game feel more polished . In the original, the map is a very colorful screen with lot's of details that don't translate very well to something that would fit within the 9918a's limitations. On top of that, as mentioned in one of the posts above, I'm reducing the scope of the game to make it feasible for me to get to a finished product. Since I've renamed it to Alex Kidd on Miracle Island, I felt the map should show, you know... an island. This was the original map screen: Nothing I tried based on this looked satisfying or professional, so I thought I could go for a more stylized look, something that's a better fit to the limitations of the VDP. I found inspiration in Super Mario 3, which does this kind of pseudo-perspective style drawing that not only hides the tricks one uses to get nice outlines around parts of the drawing but also shows elevated terrain. Also, it's a bit clearer which different levels the player can expect (I'm planning beach, plains, woods, lake, town, castle, big lake, volcano and ice castle levels, so 9 in total). I ended up with this: It's a big departure from the original, but I think it could work. What do you guys think, does this fit the game?

True, although I think the TI community is probably small enough to not get them worried...

This irks me, as they could've just reused the Spectrum graphics without much effort... lazy bums...

Cool, thanks for the link to the retrospective, looks like a nice read for when I'm at the airport later today . Yes, the game is huge... it felt so epic back when I originally got my Master System. For a built-in game it was absolutely tremendous (suck it, Gyromite/Duck Hunt!). It's very unlikely that I will do a full port, but I do intend to turn it into a full game heavily inspired by the original. At the very least I want to do some of the horizontally scrolling levels without vehicles. I also want to design new levels. I might look at adding vehicles, water levels and vertically scrolling levels at a later point in time. That's why I'm calling it Alex Kidd on Miracle Island (it kind of conveys a smaller scope). I plan on releasing one more disk image with just the current level, all polished up. After that I'm afraid I'll have to start working on tools first (ugh... dreading that) 'cause creating the level data by hand is very hard and tedious. And between 9918scroll, 9918coldet (my own command line tools for scrolling and collision detection), Magellan, Tursi's 9918convert, classic99 and vgmtool, UnHuman's GraphiCV, your Patterns, Michael's TiImageTool and MESS, Marc Rousseau's ti99sim "disk" utility, Insomnia's gcc, Rasmus' js99er, ... I'm using way too many different tools across different OS's to make it usable. I hate doing tools, but if this is to turn into an epic game, I'll have to .

Apparently it's a graphic adventure:http://en.m.wikipedia.org/wiki/Questprobe Looks pretty cool!

True that! Anyway, didn't want to derail the thread into a discussion about my C wants and needs . Although I have to say, as far as C is concerned I think it might be easier to support bank switching for program segments than for data or bss segments. It would take a modification to the compiler, but I can easily imagine a function prologue/epilogue setup that masks the paging for the developer. For data/memory manipulation, Michael is probably right, I see no direct way of fitting that in easily, and definitely not by means of a loadable library.

Oh, and there is David Pitts' older gcc port as well: http://www.cozx.com/~dpitts/tigccinst.html But I think Insomnia's port is the only C compiler that gets any real use these days.

To be honest, I haven't seen anything written with c99 since I joined Atariage. As far as gcc is concerned, besides myself I've seen things done by Tursi (libti99, Mr. Chin, his vgmplayer, ...) and Lucien (Rush Hour, Demons, Nyog'Sothep, ...). All-in-all, I think the C community is still pretty small, but if we keep improving the tools and libraries I'm sure the developers will come . Also, slowly building out a libc style library might help us eventually bring something like GEOS to the TI as well.

A completely transparent malloc/free implementation with paged memory support would be amazeballs! Especially if usable from C . It could be implemented with different back-ends, so that you could perhaps page in a swap file on a ram disk, SAMS memory, Supercart memory, ... depending on the hardware available without having to write specifically for one type of expansion.

Not in the name, but there are some sprites (8 16x16 sprites, to be exact) that are used to create the black outline on some parts of the munching Alex character.

Haven't worked much on this the past week or so, but I did spend some time drawing a start screen. What do y'all think?

Thanks for the detailed explanation. I always keep forgetting the masking functionality of the non-MSB bits in the pattern and color table location registers, since the datasheet simply says that they need to be all 1's. I'll probably play with this mode for my next project, if/when I finish Alex Kidd

Sounds dirty...

That thing is CRAZY impressive...