Now available IntyBASIC compiler v0.8 ! :)

[+nanochess]

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.

 

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

[roberto]

Looks really promising! I'll have to check this out as soon as I have some time!

Keep it up!

[Cybearg]

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?

[+nanochess]

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.

[+nanochess]

Updated to v0.8.1 because fix in IntyColor.

[Rev]

Nice! Bravo!

[First Spear]

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'!

[First Spear]

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.

[+nanochess]

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.

[First Spear]

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.

[+nanochess]

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.

[First Spear]

 

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.

[GroovyBee]

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.

[+nanochess]

Just updated IntyBASIC to v0.8.2 after locating a small bug in the SCREEN statement.

[+atari2600land]

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.

game1.asm

[GroovyBee]

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.

[+atari2600land]

I found the errors. They're either "invalid opcode" or "expression exceeds available field width."

[GroovyBee]

Where is your as1600.exe file and what size is it? I just built game1.asm fine without any errors.

[+atari2600land]

It's in libraries\documents\intvbasic\sdk1600_3\sdk1600\bin\ and it's 64k.

[GroovyBee]

Thats your problem! Mine is 477k. You need to get an updated release.

[+atari2600land]

I googled as1600 and couldn't find anywhere to download it.

[GroovyBee]

The link at the bottom of this post will get you a more up to date version of jzintv and thus as1600.

[+atari2600land]

No errors any more! Thanks GroovyBee!

[Cybearg]

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 September 21, 2014 by Cybearg

[+nanochess]

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.