Sabre Wulf

[Asmusr]

I only owned a ZX Spectrum very briefly as a child (after selling my TI I think, and before I moved on to the Amstrad CPC464), but it had some great games, and Sabre Wulf is the one that has left the strongest impression. So when I discovered an accurate map on the net I just had to transform it to the TI.

 

 

The map in Sabre Wulf consists of 256 screens arranged in a 16x16 grid. The interesting thing is that the graphics do not consist of simple 2x2 or 4x4 metatiles, but rather various odd and even sized rectangles arranged in an irregular grid. I wrote a Java program to break down the map into these metatiles and store each screen as a list of metatile references and coordinates.

 

The Spectrum has the same resolution as the TI, but only two colors per 8x8 tile/pattern. However, you still have to use full bitmap mode on the TI since there are many more than 256 patterns on a screen. This is problematic since it only leaves room for one sprite pattern table in VDP RAM.

 

The game also contains a huge amount of sprite animations - many more than we're used to on the TI. The main character alone takes up 24 16x16 sprites patterns, and if you add the sword fighting patterns it fills up the entire 2K pattern table. In addition there are a bunch of animated animals and more animations when they appear and disappear. The Spectrum had direct access to the video RAM so this was no problem, but on the TI the sprite library would probably have to be reduced considerably. With a clever scheme you could probably upload more patterns on the fly without causing too much delay, but there are also some big sprites like the Wulf/wolf that would be problematic because of the 4 sprites-per-line limitation.

 

So all in all I don't know what this will evolve into, but there is a chance it might become a game.

 

Rasmus

 

P.S. If you want to try Sabre Wulf on a Spectrum follow this link.

 

-------------------------------------------------------

 

26 Nov 2014: Final cartridge version added.

SabreWulfDemo.zip

SabreWulf-1.0.5.zip

SabreWulf-cart-1.2.1.zip

SabreWulf-cart-1.3.1b.zip

[+eebuckeye]

That is extremely impressive! Hope it becomes a full game!

[+Vorticon]

This is quite a teaser! From your description, there are certainly a lot of challenges to be overcome, but what a game this would make! It is so sad that we missed out on the true potential of the TI in its heydays...

[Gazoo]

Very nice.

 

When you're done with this 'Wolf/Wulf', would you like to port another 'Wolf'"? My favorite video game of all time is 'Sea Wolf' (It's one of the few games I can actually play). I'd love to be able to play it on a TI.

 

Gazoo

[+OLD CS1]

Nicely done! Okay, as I am beginning my voyage into the realm of game programming on the TI and am frequently thwarted by my work and responsibilities at home, I have to be prying and ask... what the hell do you do for a living? Whatever you do that allows you enough time to do this amazing stuff escapes me.

[RXB]

I think this is a SAMS concept as the 1 Meg of SAMS would speed up the disk access that would slow the program down.

 

And 1024K of memory would allow a huge map.

[GroovyBee]

Looking good! The only problem I can see so far, is that the dude moves too slowly compared to the original game.

[Willsy]

Yes! This looks great! Regarding the animation: the spectrum has no hardware sprites at all. Just the bitmap screen (no text modes either! ). To animate, the spectrum must remove the previous sprite from the screen and then write the new one. I would take a similar approach on the TI. Just write the new pattern data for a sprite from cpu ram to its appropriate location in the sprite definition table. I.e only one sprite definition table should be required.

 

And yeah the dude needs to move a little faster :-) He probably moves by two or three pixels on the spectrum version.

 

Awesome job. I hope you can finish this one. I played the hell out of this on my spectrum in the mid 80s! This would look so great on the VGA equipped F18.

[artrag]

Store in rom the frames of the main guy and copy them in vram on fly so to reserve the 2k for enemies

[sometimes99er]

Looks as if there's enough repeating characters on the individual screens to maybe check out standard graphics mode ? - At least if you're looking for any spare VDP memory.

Edited August 26, 2014 by sometimes99er

[Asmusr]

Looks as if there's enough repeating characters on the individual screens to maybe check out standard graphics mode ? - At least if you're looking for any spare VDP memory.

 

Nope, the 45 unique screens contain between 142 and 480 unique characters. The top two rows were converted using Tursi's graphics tool from a screen shot. Don't know why it introduced the grey colors in HI, but it was just a shortcut to show the Spectrum font.

[Tursi]

The top two rows were converted using Tursi's graphics tool from a screen shot. Don't know why it introduced the grey colors in HI, but it was just a shortcut to show the Spectrum font

 

.

The converter will only give you an exact color match if you're using the exact same palette as it is using internally, since that is what it matches against. It doesn't happen very often that a screen capture from anyone else has the same palette I selected, so that's an "error correction" you're seeing there. The easiest way to avoid it, if you know you are close, is to disable the dithering by setting all the dither factors to 0.

[unhuman]

The screens are probably algorithmically generated - just like Pitfall was.

[RXB]

Could you do like my XB program In the Dark using the map already loaded into the SAMS make it faster?

 

The character really never moves and is a static location for the sprite that is always in the middle of the screen and the map moves only.

And the character only changes definitions to look like running or changing direction.

 

Also I think a CPU to VDP works faster with a high speed move on the 9938 or 9958 but not sure about the F18.

The 9918 is slower but scrolling lately has been popular.

[Asmusr]

Yes! This looks great! Regarding the animation: the spectrum has no hardware sprites at all. Just the bitmap screen (no text modes either! ). To animate, the spectrum must remove the previous sprite from the screen and then write the new one.

 

Do you know how they did the shifting required to place the software sprites at any horizontal position? I mean, it must have been a slow affair to take two bytes from the raw sprite data, shifting each one, and ORing them together. On the TMS9900 with its 16 bit shift operations this could actually be done more efficiently. Or perhaps on the Speccy it was custom to store several shifted versions of each sprite?

[JamesD]

Do you know how they did the shifting required to place the software sprites at any horizontal position? I mean, it must have been a slow affair to take two bytes from the raw sprite data, shifting each one, and ORing them together. On the TMS9900 with its 16 bit shift operations this could actually be done more efficiently. Or perhaps on the Speccy it was custom to store several shifted versions of each sprite?

Some games used pre-shifted data so no shifting operation is required during animation. Edited August 18, 2014 by JamesD

[Asmusr]

I think I have extracted all the sprites now, a quite time consuming task. What I will try next is to make the orchids appear.

 

gfx.zip

[am1933]

I think I have extracted all the sprites now, a quite time consuming task. What I will try next is to make the orchids appear.

 

orchids.png

I assume it will be a mix of hardware/software sprites due to the old four per line limitation?, any idea if the TI sprites will exhibit the same kind of flickering that the Spectrum/BBC versions do?

[sometimes99er]

Apparently irrelevant.

Edited August 26, 2014 by sometimes99er

[Asmusr]

I assume it will be a mix of hardware/software sprites due to the old four per line limitation?, any idea if the TI sprites will exhibit the same kind of flickering that the Spectrum/BBC versions do?

 

Yes I guess TI software sprites would have color clash problems, but only for the horizontal direction. But I don't really think software sprites are a realistic alternative to hardware sprites. In any case I will see how far I can get with hardware sprites first.

 

Attached is the latest version with animated orchids (but no effects of running into them), and the Sabreman moves faster. I have removed the opening screen for now since it takes up too much RAM, but it could perhaps be loaded directly to VDP RAM.

SABREWULF.dsk

[Omega-TI]

Rasmus, I'm amazed you're pulling all this off with the standard 9918 level graphics. If you ever get around to making an F18A only game I'm sure we will all be blown out of the water. The closest I've seen to what you are doing now was with "Freddy", but that used a smaller portion of the screen and more repetitious graphic segments.

[TheMole]

Attached is the latest version with animated orchids (but no effects of running into them), and the Sabreman moves faster. I have removed the opening screen for now since it takes up too much RAM, but it could perhaps be loaded directly to VDP RAM.

 

Could it be that you uploaded an older disk image? I've wandered about for a bit but did not run into any orchids. I also still see the title screen?

[am1933]

 

Yes I guess TI software sprites would have color clash problems, but only for the horizontal direction. But I don't really think software sprites are a realistic alternative to hardware sprites. In any case I will see how far I can get with hardware sprites first.

 

Attached is the latest version with animated orchids (but no effects of running into them), and the Sabreman moves faster. I have removed the opening screen for now since it takes up too much RAM, but it could perhaps be loaded directly to VDP RAM.

I was thinking along the lines that the stationary collectable objects could be rendered as software sprites leaving the hardware sprites available for the moving characters.

I watched a playthrough of SabreWulf and the main problem regarding sprite movement seems to be in the more open areas of the playfield where the movement and generation of the sprites becomes a bit more random. The narrow "corridors" of the game very rarely seem to have more than four movable objects at any one time.(granted this would depend on how long the main character remains stationary).

 

P.S-no title screen? sob sob

[Asmusr]

 

Could it be that you uploaded an older disk image? I've wandered about for a bit but did not run into any orchids. I also still see the title screen?

 

Sorry, I have not updated the E/A#5 file SABREW, you need to run the E/A#3 file SW.

[Asmusr]

Rasmus, I'm amazed you're pulling all this off with the standard 9918 level graphics. If you ever get around to making an F18A only game I'm sure we will all be blown out of the water. The closest I've seen to what you are doing now was with "Freddy", but that used a smaller portion of the screen and more repetitious graphic segments.

 

Did you see the F18A Power Strike demo in js99er.net?

 

Actually for Sabre Wulf the F18A enhanced color mode is not very useful because it's limited to 256 characters. You could probably switch pattern tables using the scanline interrupt but there is not enough VDP RAM to support that. For Sabre Wulf I will probably use two F18A features only: 1. An option to switch to a ZX Spectrum color palette. 2. The ability to show more than 4 sprites on a line. On the 9918A I will use a flicker routine instead.