Jump to content
IGNORED

Now available IntyBASIC compiler v0.8 ! :)


nanochess

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
Link to comment
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?

Link to comment
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
Link to comment
Share on other sites

  • 2 weeks later...

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.

Link to comment
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.

Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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.

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...