Jump to content
nanochess

Now available IntyBASIC compiler v0.8 ! :)

Recommended Posts

Hi guys.

 

After a lot of work finally I've polished the IntyBASIC compiler v0.8 ;)

 

The new features are:

  • Generates warning if is unable to open the prologue/epilogue files
  • Shows total variable space used if exceeds available space.
  • Support for binary numbers, using syntax &01010101
  • Integrates music player and PLAY/MUSIC statements, 4 instruments and 3 drums
  • Integrates PAL/NTSC detection

The music player is exactly what is using Princess Quest right now (except for a change to bass), it was a thing I wanted to implement in IntyBASIC to ease music implementation but I had to create an actual game in order to put a fast player that could work for a real game :)

 

Including of course the new sample MUSIC.BAS including a couple of melodies. Of course this was the final frontier in order to develop great games in IntyBASIC.

 

The other enhancements are things that my dear users have requested. :D

 

I hope version 0.9 supports some features of LTO Flash, but I don't know until I get one of these and the programming specs.

 

Enjoy it!

 

Edit: Updated Aug/27/2014 to version 0.8.1. IntyColor solves a bug in Color-Stack mode when color is >=8 and enhances GROM reuse.

Edit: Updated Sep/12/2014 to version 0.8.2. Solves bug in SCREEN statement rendering unusable origin location using variable. Also in manual the arguments rows and cols were reversed.

intybasic_compiler_v0.8.zip

intybasic_compiler_v0.8.1.zip

intybasic_compiler_v0.8.2.zip

  • Like 11

Share this post


Link to post
Share on other sites

Awesome! Glad to see the binary in there, and it's super exciting to have a music player!

 

So the PAL/NTSC detection can determine the speed the game is running at? I didn't think that was possible! Are there different color palettes like with the Atari 2600, allowing one cart to automatically adjust to display the right palette/scanline count from a single cart now?

Share this post


Link to post
Share on other sites

Awesome! Glad to see the binary in there, and it's super exciting to have a music player!

 

So the PAL/NTSC detection can determine the speed the game is running at? I didn't think that was possible! Are there different color palettes like with the Atari 2600, allowing one cart to automatically adjust to display the right palette/scanline count from a single cart now?

 

Yep, the PAL/NTSC detection is to adjust music frequency, and it can be used by the programmer for the game.

 

There are no different color palettes as far as I know and the screen size is the same for both PAL/NTSC.

  • Like 3

Share this post


Link to post
Share on other sites

I pulled down v.8.1 and tried the test and music and game samples.

 

Awesomeness. Pure awesomeness. Just, wow.

 

Thanks for putting the time into this nano'!

  • Like 1

Share this post


Link to post
Share on other sites

How is the music done? Say I have a few old-school MOD and MIDI sequences. What would be the smartest way to export them into something I could re-sequence into IntyBASIC-ready musi?

 

 

Thanks.

Share this post


Link to post
Share on other sites

How is the music done? Say I have a few old-school MOD and MIDI sequences. What would be the smartest way to export them into something I could re-sequence into IntyBASIC-ready musi?

 

 

Thanks.

 

The easiest way would be to use a tracker software to see the notes and octaves and then enter notes per line (MUSIC statement)

 

Another way is entering directly from music sheet, as I've done for the Bach Invention. For example compare it with the freely available music sheets in Internet.

 

I think it's possible to develop a tracker software to edit music, run the IntyBASIC compiler and play the music, but I refrain of it because I would have to program multiplatform interfaces (PC, Mac, Linux), and I don't have enough time for it.

Share this post


Link to post
Share on other sites

I am interested in making a scrolling background. Is there a "cookbook" available that steps newbies through making several background images on a Windows Pee Cee, converting the images intycolor into background cards, and then wrapping them up into an IntyBASIC program that would convert into an executable to just scroll the images? I think something like that would go a long way with getting the unitiated (like me) started.

Share this post


Link to post
Share on other sites

I am interested in making a scrolling background. Is there a "cookbook" available that steps newbies through making several background images on a Windows Pee Cee, converting the images intycolor into background cards, and then wrapping them up into an IntyBASIC program that would convert into an executable to just scroll the images? I think something like that would go a long way with getting the unitiated (like me) started.

 

Not yet!

 

Check the sample SCROLL.BAS

 

The SCREEN statement allows to use origin + target offset, you could make a image to scroll continuously.

 

Using several images would be more difficult because the GRAM isn't shared between several images and must be redefined.

  • Like 1

Share this post


Link to post
Share on other sites

 

Not yet!

 

Check the sample SCROLL.BAS

 

The SCREEN statement allows to use origin + target offset, you could make a image to scroll continuously.

 

Using several images would be more difficult because the GRAM isn't shared between several images and must be redefined.

 

 

Thanks. I will try out the SCREEN statement as you said. I have an idea for a game, and IntyBASIC seems like the best way to do it. I know you have your own schedule for building-out the language, but if you can spend any time on doing that with the background, it would make a huge difference for me.

 

Thanks again. More questions to follow, I'm sure. :)

  • Like 2

Share this post


Link to post
Share on other sites

Personally, I use Tile Studio to generate levels for my games. It supports a scripting language that will allow you to output the data in a form readable by IntyBASIC/SDK1600. For long levels you might want to look at RLE compression to save ROM space. However, if you can move left/right horizontally that'll complicate matters for compressed level data. There are other approaches to long levels too, for example, in my Mars Minis game "Caverns" I generate the landscape procedurally so that its different every time you play. That way, you can't memorize the game path which adds replayability for a simple game.

  • Like 4

Share this post


Link to post
Share on other sites

Hi. I downloaded v.8.2 in hopes that I could get that running. Instead, I get 9 errors. Why can't it tell me what the errors are? Anyone? I am trying to compile game1.bas. I attached the resulting asm. Let's play "Spot the Errors" because I don't know how.

post-9475-0-33137600-1410809878_thumb.png

game1.asm

  • Like 1

Share this post


Link to post
Share on other sites

You should have a a file called game1.lst in the same directory as your source code. Search for the word "ERROR" (without the quotes) in that file to find your errors.

Share this post


Link to post
Share on other sites

I've been designing some sprites for an idea, but since I'll be using 2-color sprites (requiring two superimposed sprites) and animation frames add up quickly, I'm seeing how that 64-tile limitation can be pretty restricting at times.

 

My current thinking is to have 4 x 2 tile sets for each sprite (4 total, since 8/2 = 4) set aside, which means 8 x 4 = 32 of 64 tiles will be reserved for sprites only, while the remaining 32 can have background cards. 32 should be plenty.

 

The complication, though, is that there are multiple "states" to characters, each of which would take up at least 3 of those 4 reserved tile pairs. For instance, there is walking, idling, firing, and dying. That's not a problem so long as states can be fully represented with 4 tile pairs or less. The only complication I see is, since you can only load one set of tiles into memory at a time, there could be multiple sprites on-screen requiring their states to change simultaneously.

 

Is there any user-defined stack that I could use to queue up state changes, so card sets could be loaded in at subsequent frames? Even if it took 4 frames to load the correct cards, it would be fast enough that the visual complication should be minimal as long as the process can be streamlined.

 

Also, since any combination of states could be represented on-screen at once for any of the sprites, how would you recommend that I handle the DEFINE statements? I could arrange sprite data in labels by state so entire states are loaded at a time, but that means 4 labels per character type x 4 sprites x at least 6 character types = at least 96 DEFINE statements to account for all possibilities across different sprites and different character types, and a mess of branching logic to account for it all. If only I could define the card_num as a variable!

 

Any suggestions for a good way to handle this?

 

Also, on an unrelated note, is there any way to include one .bas file into another? I would rather define card data in a separate file so it doesn't clutter up the main .bas file.

Edited by Cybearg

Share this post


Link to post
Share on other sites

The complication, though, is that there are multiple "states" to characters, each of which would take up at least 3 of those 4 reserved tile pairs. For instance, there is walking, idling, firing, and dying. That's not a problem so long as states can be fully represented with 4 tile pairs or less. The only complication I see is, since you can only load one set of tiles into memory at a time, there could be multiple sprites on-screen requiring their states to change simultaneously.

 

Is there any user-defined stack that I could use to queue up state changes, so card sets could be loaded in at subsequent frames? Even if it took 4 frames to load the correct cards, it would be fast enough that the visual complication should be minimal as long as the process can be streamlined.

 

Also, since any combination of states could be represented on-screen at once for any of the sprites, how would you recommend that I handle the DEFINE statements? I could arrange sprite data in labels by state so entire states are loaded at a time, but that means 4 labels per character type x 4 sprites x at least 6 character types = at least 96 DEFINE statements to account for all possibilities across different sprites and different character types, and a mess of branching logic to account for it all. If only I could define the card_num as a variable!

 

Any suggestions for a good way to handle this?

Currently the arguments to DEFINE should be constants, I'll try to allow for expressions in a future IntyBASIC revision.

 

Also, on an unrelated note, is there any way to include one .bas file into another? I would rather define card data in a separate file so it doesn't clutter up the main .bas file.

Also in the TO-DO list.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...