XB256 teaser demo

[senior_falcon]

I've attached a zipped folder containing the program XB256DEMO. This shows some of the features XB256 adds to Extended BASIC. XB256 lets you use either of two screens, SCRN1 and SCRN2. SCRN1 is the normal XB screen and works as you would expect. SCRN2 lets the programmer use up to 256 characters, more than twice the 112 that XB allows. Moreover, you can use all the 112 character definitions normally available to XB to define sprites. To access SCRN2 assembly subroutines are used instead of CHAR, CHARPAT, COLOR, and CHARSET. Other than that all XB statements work for either SCRN1 or SCRN2. There are a number of custom subroutines to handle various scrolling tasks.

 

When you RUN the program it will issue an error message. RUN the program again and it will run normally. This quirk is because an XB pointer is changed and will NOT be a problem in the actual release. When done with the program be sure to quit, otherwise if you try to run another program it will crash. The 256 characters + 28 sprites demo is very slow and not very interesting from a graphics standpoint. The point of it is to show that you actually can define 256 unique characters and have 28 sprites all with unique character definitions.

 

I need to write the docs and clean up the code a bit. The actual release will be in a week or two.

XB256D.zip

[Retrospect]

Hey I'm loving this!

 

With the pixel scrolling, the 3-d effect you describe is in fact what most games used to call "Parallax Scrolling" ... Shadow of the Beast used it to good effect, and other such games.

 

I have a game planned, that will make use of the smooth pixel scrolling ..... I have other ideas floating around too

The extra definable characters is something I've been needing for a long time .... thankyou for this Harry.

[senior_falcon]

Forgot to mention - when the demo is running press Funtion 4 to break the program. You can list the program, look at variables, etc. Then type CON (be sure it is in caps -will fix that later). Pretty cool, eh?

[+retroclouds]

Impressive work. Also very nice that when using FNCTN-4 to break the program everything returns back to normal.

 

Cool stuff!

[RXB]

I am using Classic99 and it does nothing at all in XB or RXB but reset to the Title Screen or lock up?

 

Any idea why?

 

Screen is blank in XB or RXB and if I press FCTN 4 it breaks but nothing changes.

If I type CON it just does nothing in XB or RXB?

 

So what is is supposed to do?

Edited February 10, 2013 by RXB

[Tursi]

Very, very nice

 

Works in Classic99 here...

 

Edited February 10, 2013 by Tursi

[Retrospect]

I am using Classic99 and it does nothing at all in XB or RXB but reset to the Title Screen or lock up?

 

Any idea why?

 

Screen is blank in XB or RXB and if I press FCTN 4 it breaks but nothing changes.

If I type CON it just does nothing in XB or RXB?

 

So what is is supposed to do?

 

Which revision of Classic99 are you using? Because I'm on v365 and I didn't seem to get any problems with this at all.

As far as I know, Harry pretty much works his arse off to get these softwares to work both on the real metal and classic99.

Edited February 11, 2013 by Retrospect

[unhuman]

So cool. I've got my first 2 ideas for my compiled XB games... Don't think I'd be using this, but this certainly will fix all sorts of problems I had fitting games into such restricted color sets and characters.

 

Just need to find some time... Probably take me a few days to get the game sort of working in regular XB (where it will fundamentally suck) and then hopefully make it kick ass when compiled.

 

-H

[RXB]

Which revision of Classic99 are you using? Because I'm on v365 and I didn't seem to get any problems with this at all.

As far as I know, Harry pretty much works his arse off to get these softwares to work both on the real metal and classic99.

 

LOL I forgot I had cut and pasted the XB program into Classic99 several hours before we went shopping.

When I came back from shopping it kept crashing.

When I copied the file from the Zip it works fine.

[Retrospect]

LOL I forgot I had cut and pasted the XB program into Classic99 several hours before we went shopping.

When I came back from shopping it kept crashing.

When I copied the file from the Zip it works fine.

 

hehe ... way ta go.

[kl99]

So, this is the XB version of the demo that uses your assembler routines, right?

Once this is compiled, it will even get faster...

 

Will the new version be compatible with programs made for the XB-Compiler v2.1?

[senior_falcon]

LOL I forgot I had cut and pasted the XB program into Classic99 several hours before we went shopping.

When I came back from shopping it kept crashing.

When I copied the file from the Zip it works fine.

As you found out, you can't copy and paste when there is embedded code. In this case there is a CALL LOAD that tells the CALL LINK routine to go to a lookup routine in high memory. Without that code there the program will crash the first time it does a CALL LINK.

 

These routines will be going into the compiler soon. You will see some improvement in speed when compiled, but since they are already written in assembly the speed increase will not be great. CALL LINK takes time (about 1/50 second), passing variables, converting to integer, etc all use up time in XB and this part is much faster when compiled. Once all that is done the actual routines should only be a bit faster, and that mostly because the registers are on the 16 bit bus.

[kl99]

I will show this demo (preview) on the Vienna TI meeting this wednesday as well. Thanks a lot for your answers.

[senior_falcon]

So, this is the XB version of the demo that uses your assembler routines, right?

Once this is compiled, it will even get faster...

 

Will the new version be compatible with programs made for the XB-Compiler v2.1?

 

Thanks for demonstrating this in Vienna!

 

I'm not quite sure what you mean about compatibility. If you have spent a lot of time writing a program that works with XBCompiler 2.1 then it will work with the revised compiler when it comes out. On the other hand, if you write a program that uses the added subroutines in XB256, you cannot use XBCompiler 2.1 because the routines are not built into it.

[kl99]

Sure, I meant upwards compatibility. My current program uses the XB Compiler 2.1 features. Since there are no breaking changes planned from your side, it should work like before when compiled with the upcoming Compiler version.

[senior_falcon]

It should be completely compatible, EXCEPT...

There is one change I am thinking of making. As written the sprite early clock is set as follows:

CALL LINK("EARLYC",714) would set the color of sprite 7 to 14 (magenta) with the early clock set.

I might change this subroutine so that:

CALL LINK("EARLYC",7) would set the early clock of sprite 7 without changing the color. The code for this is a bit more compact and I think it is more intuitive. One possible consequence is that if you changed the color of the sprite it would jump 32 spaces to the right, then jump back when you set the early clock again. This probably wouldn't even be visible in a compiled program, but I think it would be visible when running in XB.

The code is written - any thoughts on whether I should make the change?

[unhuman]

I know nothing of this stuff, but can you make call links take multiple parameters? If so, separating the sprite # and the color would make a lot of sense. And, maybe the 2nd parameter could be optional?

[sometimes99er]

It should be completely compatible, EXCEPT...

There is one change I am thinking of making. As written the sprite early clock is set as follows:

CALL LINK("EARLYC",714) would set the color of sprite 7 to 14 (magenta) with the early clock set.

I might change this subroutine so that:

CALL LINK("EARLYC",7) would set the early clock of sprite 7 without changing the color. The code for this is a bit more compact and I think it is more intuitive. One possible consequence is that if you changed the color of the sprite it would jump 32 spaces to the right, then jump back when you set the early clock again. This probably wouldn't even be visible in a compiled program, but I think it would be visible when running in XB.

The code is written - any thoughts on whether I should make the change?

 

How about going for the change and then adding a replacement setting sprite color, like CALL LINK("SPRCOL",7,14), but with this not affecting the state of the early clock.

 

XB Compiler 2.1 Documentation.pdf

 

CALL LINK(“EARLYC”,NUMBER[...])

 

The early clock is not supported by Win994a.

 

Instead of using the 1st bit as early clock, last time I checked (2008), Win994a used the 4th bit. When I was trying out the early bit, I misread the E/A manual (as did apparently the author of Win994a) and fiddled with the 4th bit, so Win994a would work, but MESS and Classic99 wouldn’t. I guess you can safely manipulate both bits.

 

Edited February 12, 2013 by sometimes99er

[+acadiel]

Nice demo!!!!! I'm impressed!