Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

Cybearg

Members
 View Profile  See their activity

  • Content Count

    951

  • Joined

  • Last visited

Posts posted by Cybearg

  1. Posted · Edited by 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.

  5. Posted

    On the Atari 2600, there are TIA registers that can be set to cause multiple instances of a single sprite to display in a horizontal row, like so:

    x1: x0.png

     

    x2: x1.png

     

    x3: x3.png

     

    This still only counts as one sprite because the kernel is just drawing the sprite three times in a row.

     

    Is there any equivalent of this for the Intellivision, or could it be added in somehow? This little trick can be enormously useful for making one sprite seem like a lot more, and while it's great that there are 8 sprites for the Inty, I have a few use cases that would supremely benefit from this functionality.

     

    Can it be done?

  6. Posted

     

     

    Pretty much your best bet is to subvert newcolecos C devkit to parse BASIC ala BCX or support nitrofuranos effort to port ZX Basic to various platforms.

    If it's already a stretch to compile C/BASIC into Assembly due to memory/size inefficiencies, I assume the problem would only be compounded if you convert BASIC to C, then C to Assembly, then Assembly to machine code. That's an awful lot of conversions for a low-spec system like Coleco.

     

    More likely I'll just have to use C with a bit of Assembly if I want to get into it. I just like the convenience and readability of BASIC when it comes to these older systems. Part of the reason may be because sample code tends to be written uber-efficiently with minimalist documentation, making it difficult to understand what's going on with C, while it's easier to follow BASIC at a glance.

  10. Posted · Edited by Cybearg

    Right. But, he's not targeting batari BASIC in any way, shape or form. :)

    No, but programming games in C on a more modern processor would likely be more accessible to batariBASIC homebrewers than making whole race-the-beam kernels from scratch in Assembly. So it's still very relevant to those of us who aren't inclined toward Assembly programming.

  11. Posted · Edited by Cybearg

    Maybe I'm alone in this, but I think treep's proposal of shifting processing to a cheap on-cart processor would be awesome! I'd LOVE to have NES-equivalent capabilities on a 2600 cartridge!

     

    As for the question of "what's the point?", the point is that everyone who has a 2600 (a lot of people) can then play those advanced games. It only expands what the system is capable of. If there was a cartridge that could give the 2600 N64-style capabilities while still running the standard hardware, wouldn't that be pretty cool and worth doing?

     

    Expanding what can be done on a 2600 cart only expands the potential of the 2600. There will always be geniuses who push the 2600's capabilities with cutting-edge Assembly wizardry, but not everyone can do that. Would you rather have more great games, some that push native functionality and some that rely on newer assist hardware, or fewer games overall, potentially with more schlock as people who are limited by batariBasic push out only limited shovelware games because it's the best they can technically manage?

     

    Yes, the 7800 could use some love, but the 7800 doesn't have near the audience of the 2600, nor will it ever. Making more advanced things possible allows more variety for 2600 players and 2600 homebrewers while still leaving the 7800 and pure 2600 audiences in-tact. It doesn't hurt anyone to try to advance things.

    • Like 1

  12. Posted

    It would be nice if the bB DPC+ ARM code could have options you enable and disable like the 6502 kernel, so we could allow the bB coder to pick tradeoffs, but that would mean everybody would need an ARM cross-compiler.

    Is there some reason the ARM compiler can't be bundled with bB so that the ARM compiler is called to do whatever it needs to do during bB's compilation?

  15. Posted · Edited by Cybearg

    I'm noticing trouble with the latest DPC+'s playfield display. Namely, if any playfield data is defined, it becomes a flickery, crazy mess.

     

    I have tried code that worked with earlier versions of DPC+ (batari's latest releases) but now create the flickering problem I mentioned.

     

    As a comparison, here is the earlier DPC+ version: fixit.bas.bin

    post-34988-0-71143400-1410354940_thumb.png

     

    And here is the latest DPC+ version with no code changes except moving a few declarations into bank 2: fixit_dpcnew.bas.bin

    post-34988-0-15195400-1410354835_thumb.pngpost-34988-0-73422700-1410354835_thumb.png

     

    I get the same effect every time I try to do anything with DPC+ and a playfield.

     

    Is this just me? Any fixes available?

  17. Posted

    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?

  18. Posted

    First off, thanks tons for your awesome, detailed post! Unfortunately, I'm gonna have to load off my questions...

     

    I find the Color Stack superior for my own work. I much rather have the increased custom tile space than more colours, if only because more colours can be achieved with clever tricks.

    Increased custom tile space? I thought that FG/BG mode only made you lose the non-alphanumeric pre-built ROM cards? Aren't there only 64 custom RAM cards for both Color Stack AND FG/BG?

     

    Also, you're clearly using more than 4 color, there. I count at least 9. What gives?

     

    The Christmas Carol title screen was drawn in Color Stack mode, and nobody can accuse it of lacking colour :)

    attachicon.giftitle_screen.png <-- click to enlarge

     

    Very cool! It looks very complicated for tiles, but I guess it's just very clever tiling, huh?

     

    Let me see if I can explain some of the tricks used, to which I alluded before. That scene employed the following colour definition:

    COLOR_STK:  C_GRN, C_WHT, C_CYN, C_RED

FG_COLOR_0: X_CYN
FG_COLOR_1: X_GRN
FG_COLOR_2: X_WHT
FG_COLOR_3: X_RED
FG_COLOR_4: X_DGR
FG_COLOR_5: X_ORG
FG_COLOR_6: X_YEL
FG_COLOR_7: X_BLU
FG_COLOR_8: X_LBL
FG_COLOR_9: X_PNK
FG_COLOR_A: X_YGR
    The rest uses foreground colours. Notice that the colour transitions mostly follow the stack order, from green to white, to cyan, to red. I say mostly because, as you can see, cyan is not really well represented.

     

    I think I follow... The image happens to have mostly green, then white, then cyan, then red, although that's only the case in this very specific scenario. I guess it takes a lot of careful, clever design to make your scene follow these patterns while still looking dynamic and good.

     

    So, how do you get from green to white, to green again?

    From the tree to the green text, you mean?

     

    This is where clever use of the stack comes into play. My solution to skip stack colours was to advance the colour stack and use only foreground colours.

     

    Take a look at the first row:

    ; 00     01       02       03       04       ; 05     06       07       08       09       0A       0B       0C       0D       0E       0F       10       11       12       13
:COL=4,0 :COL=4,0 :COL=2,0 :COL=4,0 :COL=4,1 :COL=3,0 :COL=3,0 :COL=3,0 :COL=3,0 :COL=3,0 :COL=3,0 :COL=3,0 :COL=3,0 :COL=3,0 :COL=1,0 :COL=3,0 :COL=3,0 :COL=3,0 :COL=2,1 :COL=2,1 ; 00
......#. ........ .......x ######## ###..... ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ######## ######## ; The "O" in "Carol" needs to be overlayed
......#. ........ ..##.... ...##### #....... .#####.. ##...#.. ######.. .####... .#####.. ######## .#...#.. ..###... .#####.. ........ .#####.. ..###... ######.. ######## ..###### ; with a MOB.  This saves us one GRAM card.
......## ........ .####... .......# #....... ##....#. ##....#. ##....#. ..##.... ##...... ...##... ###.###. .#...#.. ##...... ........ ##....#. .#...#.. ##....#. ######## ..###### ;
......## ........ ..##.... .......# ##...... ##...... ##....#. ##....#. ..##.... .#####.. ...##... #######. ##...##. .#####.. ........ ##...... ##...##. ##....#. ######## ..###### ; The serifs will be overlayed with MOBs also.
......## ........ ........ ........ ###..... ##...... ##...##. ##...#.. ..##.... ......#. ...##... ##.#.##. ##...##. ......#. ........ ##...... ##...##. ##...#.. ######## ..######
.....### ........ ........ ........ #######. ##....#. #######. #####... ..##.... #....##. ...##... ##.#.##. #######. #....##. ........ ##....#. #######. #####... ######## ..####.#
.....### #....... ........ ........ ######## #######. ##...##. ##..##.. ..##.... #######. ...##... ##...##. ##...##. #######. ........ #######. ##...##. ##..##.. ######## .......#
.....### #....... ........ .......# ######## .#####.. ##...##. ##...##. .####... .#####.. ...##... ##...##. ##...##. .#####.. ........ .#####.. ##...##. ##...##. ######## #.....##
    The stack starts as green, drawing the background of the Christmas tree. It increases the stack pointer on the 5th column (as attested by second argument in my colour definitions: :COL=4,1). That coincides with the white field, which uses the second colour in the stack, and the letters are painted using a red foreground colour (:COL=3,0 means FG=FG_COLOR_3 (Red), INCREMENT=No).

     

    Ok, I think that makes sense. But what about all those tiny, multicolored details where there are balls and lights in close proximity on the tree? Also, are you able to use all foreground colors, or are you limited to only certain ones?

     

    As you can see, the stack is incremented twice on the last two cards (:COL=2,1), conveniently cycling back to the first colour, green, just in time to draw the Christmas tree on the first column of the next row.

     

    The first increment (for the letter "O") puts it on cyan, which is not used (the card is a solid block painted with FG white). The next increment puts it on red, which is then used to draw the letter "L" in "reverse video." That is, the red BG colour is used for the FG letter, and the white FG colour is used for the tile's BG.

     

    However, that left a hole on the next to last column, where the last "O" would be. (Remember that I skipped the cyan BG colour, and I can't remove cyan from the stack, for I will need it much later.) As the comments in the drawing above note, a MOB is overlaid to fill in.

    Really clever! Does this technique often work, or was it just by fortune that it happened to suit this particular case? But, if it's possible to skip more than 1 place in a stack, why didn't you do so for the O? And why does the stack cycle instead of popping, as I would have expected?

     

    Similar techniques are used for the following rows, all skipping one or two stack entries whenever possible. For instance, by the 4th row, this trick has caught up with me, and I land on the first column with a stack on the third colour, cyan. No worries, just do the same as before: paint it solid with FG colour green. (This re-uses the "solid block" card, which happens to be conveniently in GROM, and saves us GRAM space!)

    Again, really clever, but why didn't you just increment to the point in the stack that you needed? Was the compromise purely to save the GRAM space without having to load in another card?

  19. Posted · Edited by Cybearg

    Hehehe :) you didn't read the STIC Wiki ;)

    Finally read it! Initially, I thought I would be going with Mode 0 (Color Stack), but Mode 1 (BG/FG) is looking more and more appealing, now.

     

    I foresee fiddling with those color bits will be a real pain in the butt unless I make some kind of subroutine to convert/set those bits for me. Or is that handled by the BASIC?

  21. Posted

     

    • Overlaying MOBs to add additional colour
    • Clever use of the Color Stack and "reversed video" to extend the palette

    Of course, you can always do "multiplexing," but it is not very effective on the Intellivision, and therefore not very common.

    I don't know what those things mean. Could you please explain?

     

    Also, can one change the foreground/background color of cards on a per-card basis, or does setting it for one card affect all until changed?

  22. Posted

    Thanks for the answers. Sounds like it will take a lot of careful management.

     

    To repost my above edited-in question:

     

    Also, if you try to load in more than the limit of cards for a frame, will it cause a timing error in the game resulting in screen rolling, or will the game know to take its time? For instance, let's say that the limit is 16 cards per frame and I try to load 64 cards .Will the game just load 16 cards per frame for 4 frames until it's finished, or will that one frame take 4 frames' worth of processing time to complete?

  23. Posted · Edited by Cybearg

    Ok, cool!

     

    I just noticed this that I must have overlooked (or didn't understand until now) from the manual:

     

     


    DEFINE card_num,total,label
    Loads graphics in GRAM "card_num" (0-63) for a total of "total" cards.
    label points to graphics. (DATA or BITMAP)
    Graphics will be loaded in next frame.
    Only constants (not expressions) can be used in parameters.
    Note there is an approximate limit of loading 18 GRAM cards per frame
    (measured with emulator in NTSC mode)

     

    What is the "total" used for? If your data table holds, say, 16 definitions, you can then set the total to 2 in order to load two cards in at once?

     

    Does it improve the performance to batch-load 16 cards or does calling DEFINE 16 times, once for each individual card, have the same performance hit?

     

    And, when loading a card (or multiple cards) into RAM, does it reduce the number of processor cycles available for gameplay code for a frame, or does it only use cycles from the drawing processing?

     

    Also, if you try to load in more than the limit of cards for a frame, will it cause a timing error in the game resulting in screen rolling, or will the game know to take its time? For instance, let's say that the limit is 16 cards per frame and I try to load 64 cards .Will the game just load 16 cards per frame for 4 frames until it's finished, or will that one frame take 4 frames' worth of processing time to complete?

  24. Posted · Edited by Cybearg

    That's right, but you can reuse background cards or GROM tiles for sprites.

    Well, since those 64 tiles are in RAM, I suppose one could just use data tables to hold a large tile set in ROM, then just swap out a handful of tiles (16 or so) into RAM as necessary, creating a large set in the long run, right? Ditto for sprites?

     

    For instance, let's say I have 5 levels with distinct tile sets. One level may have 32 cards that get loaded in from a data table, then the second level gets another, different set of 32 cards loaded in from a different data table. Maybe it's even done on the fly depending on where you are in the level, retiring or loading in card sets in-game as you explore different portions of a level. Likewise for an enemy sprite having a certain card for it, then that card is changed in RAM for each frame of animation, rather than swapping between cards. Or is loading a card into memory too slow to be practical for frame animations like that in real time?

     

    Is this the full set of available Intellivision pre-made cards?

  25. Posted · Edited by Cybearg

    Nope. There are 256 pre-defined ROM cards. These cards are defined by a ROM chip in the Intellivision and cannot be changed.

    There are 64 cards in RAM that can be user defined and modified during game operation.

    No cards are defined in the game ROM.

    Ah, I see. Are 64 cards enough for a decent set of background tiles, or is it pretty limiting? Reusability is obviously going to be very important.

     

    There is a chance for bankswitching once I get the LTO Flash Cart and specifications. I don't hope to support any other bankswitching.

    Alright, awesome! Will that bankswitching be an option for burned carts as well, or only on the Flash Cart? And what kind of sizes will be available then?

     

    as1600 has an option to generate a listing file, you should read that file to check the addresses used.

    Right, I am making list files. I just don't know where it specifies how many bytes are free/used. Does it specifically state it somewhere?

     

    I'm not sure to understand what you're trying to say.

    I figured it out. I didn't realize that IntyBASIC has such dynamic memory management. In batariBasic, you have to specify specifically what memory locations are being mapped to variables. For instance:

     

    DIM my_variable = $50

     

    This would map "my_variable" to the memory location $50. This could then be used as a single variable:

     

    my_variable = 9

    REM this would cause $50 to hold 9

     

    Or as an array, if referenced like so:

     

    my_variable[0] = 5: my_variable[9] = 9

    REM this would cause $50 to hold 5 and $59 to hold 9

     

    Apparently in IntyBasic, you only DIM arrays. You don't DIM single variables and instead just dynamically assign them, like so:

     

    DIM my_array(3): REM 3-index array

    my_variable = 1: REM creates a new variable and gives it the value 1

     

    It's just a bit different than what I'm used to. :) The dynamic memory management is awesome, though!

    Ah, ok, you can use decimal and hexadecimal as you wrote it. I think I can support binary in the next version of IntyBASIC ;)

    Yes, please! That would be great!

     

    I understand. No, I don't have support for that style of bit operations.

     

    I'm trying hard to not include anything "heavy" which could be hidden and slow.

    Aw... Well, maybe you'll think of an efficient way to add that in. It's awfully convenient.

     

    Only 64 GRAM cards available and only 8 sprites available, 8x8 sprites would require 8 GRAM if every one is different, or them could share one GRAM if same drawing.

     

    8x16 sprites would require from 2 GRAM to 16 GRAM, at your choice.

    So sprites count against the memory available for background cards?
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...