senior_falcon Posted February 10, 2013 Share Posted February 10, 2013 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 2 Quote Link to comment Share on other sites More sharing options...
Retrospect Posted February 10, 2013 Share Posted February 10, 2013 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. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted February 10, 2013 Author Share Posted February 10, 2013 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? Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted February 10, 2013 Share Posted February 10, 2013 Impressive work. Also very nice that when using FNCTN-4 to break the program everything returns back to normal. Cool stuff! Quote Link to comment Share on other sites More sharing options...
RXB Posted February 10, 2013 Share Posted February 10, 2013 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 10, 2013 Share Posted February 10, 2013 (edited) Very, very nice Works in Classic99 here... Edited February 10, 2013 by Tursi Quote Link to comment Share on other sites More sharing options...
Retrospect Posted February 11, 2013 Share Posted February 11, 2013 (edited) 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 Quote Link to comment Share on other sites More sharing options...
unhuman Posted February 11, 2013 Share Posted February 11, 2013 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 Quote Link to comment Share on other sites More sharing options...
RXB Posted February 11, 2013 Share Posted February 11, 2013 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. 2 Quote Link to comment Share on other sites More sharing options...
Retrospect Posted February 11, 2013 Share Posted February 11, 2013 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. Quote Link to comment Share on other sites More sharing options...
kl99 Posted February 11, 2013 Share Posted February 11, 2013 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? Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted February 11, 2013 Author Share Posted February 11, 2013 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. Quote Link to comment Share on other sites More sharing options...
kl99 Posted February 11, 2013 Share Posted February 11, 2013 I will show this demo (preview) on the Vienna TI meeting this wednesday as well. Thanks a lot for your answers. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted February 11, 2013 Author Share Posted February 11, 2013 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. Quote Link to comment Share on other sites More sharing options...
kl99 Posted February 11, 2013 Share Posted February 11, 2013 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. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted February 12, 2013 Author Share Posted February 12, 2013 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? Quote Link to comment Share on other sites More sharing options...
unhuman Posted February 12, 2013 Share Posted February 12, 2013 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? 1 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted February 12, 2013 Share Posted February 12, 2013 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+acadiel Posted February 14, 2013 Share Posted February 14, 2013 Nice demo!!!!! I'm impressed! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.