Sabre Wulf

[JonnyBritish]

Underwurlde. I wonder how many *weeks* I burned up on that game!

 

Ditto

 

also Tir Na Nog :-)

[Willsy]

Tir Na Nog! I never got ANYWHERE with that game, other than making the man walk left and right! Lovely animation though!

[JonnyBritish]

I got further it seems...even submitted a map to Crash magazine :-)

 

what we really need on TI is Lords Of Midnight :-)

 

Luzor stands looking across the Frozen Wastes to the land of TI

[am1933]

Meanwhile back on planet Sabrewulf-the TI game area looks pretty much identical to the Spectrum version both in terms of colour and resolution(So what-I hear you say!)

 

On the proviso that the game mechanics are similar to the spectrum version it should give us some bragging rights, the C64 version has that terrible washed out pallete that all C64 games have, the BBC micro version is slightly blockier than the original-and I won't even bother with the Spectrum versions sound, Amstrad version suffers from the same kind of resolution as the BBC version and also has the same flickery software sprite problem as the spectrum and BBC.

 

Things are looking good.

[mäsäxi]

I know how you feel. Just when you think it cannot get any better on the TI, the guy comes out and tops himself yet again. And the pace in which he does these programs it truly mind shattering, he's on track to average what, about three new programs per year?

 

I bow to Rasmus, one of the TI Gods!

 

 

Oh please, take a cold shower.

But then he´s doing the same Naked!

[Asmusr]

Here is the latest demo with basic animal/enemy sprites added, but lots of things are still not working as they are supposed to. You can meet the wolf and the guardian on screen 2, for instance, and you can't die.

 

 

There is quite a lot of sprite flickering, but I don't think it's worse than the color splash on the ZX Spectrum. Anyway, most of you will have F18As and no flickering.

 

Most of the original sprite patterns are there, but I can't fit them all in without switching to a cartridge only game, which I might do anyway at some point (I currently have about 2K RAM left). The patterns for the sticks when a sprite appears and the puff of smoke when it disappears are taking up half of the VDP sprite pattern table, but the conversion would not be the same without them.

 

The annoying thing about the Spectrum sprites is that the sizes are not multiples of 16x16 pixels, but often something like 24x18. This means many sprites are almost empty, and it wastes both CPU and VDP RAM. You could store the patterns in CPU RAM in their original sizes, of course, but that adds another level of complexity.

 

Rasmus

 

 

 

 

 

 

SabreWulfDemo3.zip

[Iwantgames:)]

Wow this looks awesome!!!

[sprintcarfan]

Hmm, I can't seem to get Demo3 to work properly. SW with EA3 give a black screen with a few random bars in the lower right of the screen, and SABREW with EA5 gives a black screen with a lot of random graphics. I'm getting the same result in Win994a. I'm a bit of a noob, so maybe it's something dumb I'm overlooking.

 

John

[Asmusr]

Hmm, I can't seem to get Demo3 to work properly. SW with EA3 give a black screen with a few random bars in the lower right of the screen, and SABREW with EA5 gives a black screen with a lot of random graphics. I'm getting the same result in Win994a. I'm a bit of a noob, so maybe it's something dumb I'm overlooking.

 

John

 

I don't expect it to work in Win994a (none of my programs do), but are you saying it's not working on the real hardware either? Which type of disk drive are you using?

[sprintcarfan]

Nanopeb V1.

[Asmusr]

Nanopeb V1.

 

Strange, I tried it on a nanoPEB last night.

 

Is anyone else having the same problem?

[+Vorticon]

Is the latest demo supposed to just display the splash screen because that's all I get. After that there is no response. This is under Classic 99.

[Asmusr]

Is the latest demo supposed to just display the splash screen because that's all I get. After that there is no response. This is under Classic 99.

 

You have to press fire to continue.

[+Vorticon]

 

You have to press fire to continue.

 

I thought so, but pressing Q (or any other key for that matter does not do anything). Under Classic 99, the Q key is the emulated fire button normally...

[Asmusr]

 

I thought so, but pressing Q (or any other key for that matter does not do anything). Under Classic 99, the Q key is the emulated fire button normally...

 

Classic99 is mapping fire to the Tab key. AFAIK fire and Q are not related by anything other than the KSCAN routine.

[+Vorticon]

Yes, Tab did work. Funny thing is that I have always used the Q key as the fire key in all the games I have tested in the past, never the Tab key. Go figure...

This demo is pretty sweet by the way. Amazing work on your part.

Edited September 11, 2014 by Vorticon

[Tursi]

Yes, any software that uses KSCAN will map joystick fire button 1 and Q to the same scan return code, but software that scans CRU directly can actually tell them apart, the joystick is on a different line.

[Asmusr]

http://youtu.be/gBviozwSDWA

 

This video has a few more elements implemented than demo 3, for instance most of the orchid conditions now work.

[Asmusr]

Yes, any software that uses KSCAN will map joystick fire button 1 and Q to the same scan return code, but software that scans CRU directly can actually tell them apart, the joystick is on a different line.

 

One call to KSCAN takes around 27000 clock cycles. That's about the same time my Sabre Wulf demo uses for the entire game loop - even without attempting to optimize the code. I accuse KSCAN for being the #1 reason for slow games on the TI.

[+Lee Stewart]

 

One call to KSCAN takes around 27000 clock cycles. ...

 

Not so—unless there's actually a key waiting. If no key was pressed, it's pretty short—probably still significant, though.

 

...lee

[RXB]

I wrote CALL IO in RXB to let people use a CRU scan of JOYSTICK or KEY lines but oddly no one has taken advantage of this speed increase.

100 DISPLAY AT(1,1)ERASE ALL:"THIS PROGRAM CHECKS FOR     UNUSUAL KEYS BEING PRESSED, EVEN IF MORE THAN FOUR KEYS ARE BEING PRESSED AT ONCE"
110 CALL IO(2,16,3,A,B) :: IF A=18 AND B=255 THEN 110 ELSE CALL HPUT(24,3,RPT$(" ",30),24,24,STR$(A)&"  "&STR$(B))
120 IF A=146 THEN CALL HPUT(24,3,"FUNCTION KEY")ELSE IF B=191 THEN CALL HPUT(24,3,"CONTROL KEY")ELSE IF B=223 THEN CALL HPUT(24,3,"SHIFT KEY")
130 IF B=251 THEN CALL HPUT(24,3,"ENTER KEY")ELSE IF B=253 THEN CALL HPUT(24,3,"SPACE BAR")ELSE IF B=254 THEN CALL HPUT(24,3,"PLUS/EQUAL KEY")
140 GOTO 110

Using the CRU for JOYST line or for Q key line the RXB command CALL IO would be faster way to then CALL KEY for JOYST or KEY checking.

[sprintcarfan]

 

You have to press fire to continue.

The fire button was the problem for me as well, but it seems the splash screen looks corrupted on my machine? Either way, quite an amazing looking game to run on this ancient hardware. Looks like the current version might be difficult once the damage is enabled... the enemies spawn quite frequently.

[Asmusr]

 

Not so—unless there's actually a key waiting. If no key was pressed, it's pretty short—probably still significant, though.

 

...lee

 

True, but there is quite a lot of keypressing going on during gameplay.

[Asmusr]

If you want to display a bitmap mode screen while loading the main program you only have a 2K file buffer available in VDP RAM. If you split an E/A#5 file into 2K segments, will it still load with E/A, and do we have any tools for doing the splitting? Or is it better to convert the main program into one or two IF128 files? What has other people done?

 

Thanks,

Rasmus

[+OLD CS1]

A bit aside, is loading via VDP RAM buffers a Monitor or DSR requirement? I am just wondering why we cannot ourselves over-come this and load things into CPU RAM directly.