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

    Well, thanks to everyone for the information! It's a relief to hear that I have options.

     

    For the time being, I'll juts continue development as is, testing the levels one by one. I like the idea of possibly combining page flipping with compression to maybe get longer levels in. In any case, I'll be waiting on IntyBasic to offer native page flipping support, as that seems to be the crux of things.

    • Like 2

  3. Posted · Edited by Cybearg

    No, that makes sense, freeweed. Same to you, intvnut. However, I'm sure that these compression techniques require some ASM that I have no idea how to code. Maybe nanochess is reading this and can offer suggestions or encouragements for planned IntyBasic support of this kind of thing.

    Luckily for me, I made the program that I'm writing the maps with, so getting it to export compressed data shouldn't be too difficult. :) I just don't know how exactly to use it in the most optimally-efficient way. Heck, maybe the compression could be combined with the page-flipping?

    By the way, by "page-flipping," are you referring to "bank switching"? Not that it matters, but banks in the 2600 are up to 4k. I had to work a fair bit with them in the development of Piñata (sort of), and it wasn't a problem. Having level data in different banks that I need to switch to, read out the bytes, then switch back to the main program to continue? Pff, piece of cake from a software design standpoint. I have no idea of the complications and process from a software architecture standpoint, though. If it's like the way batariBasic does it, it's as simple as specifying a subroutine and a bank to jump to, then returning from it.

     

    Oh, and the game is horizontal scrolling from left to right only; no need to worry about going backward or up/down.

     

    What is the practical size available to me for the Intellivision/IntyBasic without page flipping, and what is available WITH page flipping? Does non-page flipped Intellivision work on 8kb banks as well, or is there some standard 16k bank for non-page flipped and a smaller version for page flipped?

  4. Posted · Edited by Cybearg

    Use bits instead of bytes...

    Encode the data differently...

    While this is technically correct that there is a lot of wasted bits, I don't see how that's particularly useful. It's not like you can just mash bits together and get coherent data; the position of those bits encodes some of the information.

     

    Sure, I might only be using 13 out of 16 bits, but what am I going to do with the remaining 3 bits of that word? I can't just begin another word part-way through an existing word and get any coherent data out of that.

     

    Use compression.

    Are there any ASM algorithms that could decode encoded data fast on the fly? If so, that would be great, but I have no idea how to encode or decode words.

     

    Use random numbers starting with a known seed.

    Well, the game's design isn't really based around randomness. Pretty much every level is intentionally designed with particular enemies placed in a precise location. It doesn't run off of a seed.

     

    I'm sure there are more ways besides completely laying out each screen character by character and byte by byte.

    Wish someone had told me that before I made a program to help me to exactly that. :P

     

     

    You could certainly make it work uncompressed, but you'd probably end up with some page-flipping. Or, you could implement some simple forms of compression.

    I'm totally okay with page-flipping, whatever that means! How do I do that with IntyBasic? Whatever it takes to make this work with as few sacrifices as possible.

     

    Let me see if I can recreate your math:

    • 10 "screens": I assume you mean 20 x 12 x 10 = 2400 display characters of level data
    • 6 stages x 3 levels/stage = 18 levels total
    • 18 * 2400 = 43200 characters
    • 2 bytes / display word = 86400 total bytes
    Is that how you came to the numbers?

     

    Exactly.

     

    For one, you could probably compress down to bytes instead of storing words for each display element...

    So, for instance, there would be:

    word_table:
   data $F803, $C905
   ...

locations_table:
   data 0, 5, 8, 20, ... $F03, $F93...
   data 3, 9, 13, ... $801 ...
    Or something along those lines? A problem is that I have a scrolling game, so the correct tile data for a column has to be read in at just the right time. This table scatters that data around and would, I'd think, require a mess of processor time and memory to unjumble it all in real time for new cards to be fed in.

     

    Just cutting the data in half with no further compression gets you down to 21K words, which, while large, is still quite manageable...

    How do I do compression?

     

    The Atari 2600 and the 7800 both have options for chips that are 128-512+ kb with (from what I understand) no or little trouble in the process. Is there no option like that--just burning the ROM onto a bigger chip that is dirt-cheap these days?

     

    What's all this stuff about pages and how does that work? What's the catch?

     

    For the record, each screen will have more or less this level of detail:

    post-34988-0-28011300-1413432862_thumb.png

     

    I'm not sure if that's considered dense or not, but most of the game will incorporate only a handful of variations on mostly the tiles you see displayed here.

  6. Posted · Edited by Cybearg

    I'm currently working on a scrolling Intellivision game. I would like each level to have 10 screens (at least) so that the levels have a decent length (by my estimations, it would take between 6 and 7 minutes to complete). I want three levels per stage and a total of six stages in the game.

     

    The problem is that comes to 86,400 bytes of map data alone!

     

    Should I panic? What can I do to get a decent-sized game within what seem to be very strict ROM limitations? Is this not as big of a concern as I'm making it out to be, or should I panic?

  7. Posted

    In case you're wondering whether this works on a real INTV or not. It even works on an INTV2, which is more than I can say for some cartridges (cough *coleco*)

     

    Is there a significant risk that games WON'T work? I'd think that being designed in IntyBasic would essentially guarantee compatibility unless you start doing a lot of weird ASM tweaks. Is that not the case?

  9. Posted

    OMG I want to have a crack at that tile editor! Do you draw with it and it figures out the code?

    If you mean drawing with tiles and it spits out the formatted screen data, then yup!

     

    OK, played with it some - very nice for an "inexperienced programmer". How did you get the GRAM tiles in there, for those last pics? Is that what the import .csv does?

     

    This is actually pretty feature-complete for what you're aiming for, but a couple of things would be keen. 1. a way to start over (new, clear, whatever) without restarting the app. 2. A grid showing the 8x8 cards. The first might be fairly easy, the second I'm not sure.

     

    I know I'll be messing around with this in the near future.

    If you have the STIC set to one of the GRAM options (whether stack or fgbg) a "Load" button appears. It will let you select your own tileset to replace the default GRAM tileset. It's looking for 16 x 4 16-pixel square tiles (so 256 x 64). Most likely you'll want to actually create a 128x32 tileset using 8x8 tiles, then uprez it to 16x16 tiles. That's what I did in those examples and, yes, that's what those sample images do.

     

    The .csv files are created with the "save" button. They're just the raw numbers for the program to read using the "load" button. If you want the values formatted for IntyBasic, use the "export" button.

     

    Noted on the clear button--that should be easy to implement. What do you mean by the tile thing, though? Just that you want to have an option for clearly seeing a grid between the on-screen tiles?

  10. Posted · Edited by Cybearg

    I should have done this in the first post, but here are some screenshots and examples.

    SpriteAid
    post-34988-0-52477300-1413320012_thumb.png


    IntyMapper

    Color Stack Mode
    post-34988-0-62775800-1413320027_thumb.png
    post-34988-0-82248800-1413320120_thumb.png
    sunny_day.csv.txt

    Foreground-Background Mode
    post-34988-0-35336400-1413320051_thumb.pngpost-34988-0-06394900-1413320052_thumb.png

    post-34988-0-44225400-1413320498_thumb.pngpost-34988-0-64582300-1413320809_thumb.png

    post-34988-0-70919000-1413320124_thumb.png
    greenhead_games.csv.txt

    Peek at the Green Games output:

    screen_0:
data $0000,$0000,$0000,$0000,$0000,$0000,$0000,$0000,$0000,$0000
data $0000,$0000,$0000,$0000,$0000,$0000,$0000,$0000,$0000,$0000

data $0000,$0000,$0000,$0CB0,$0400,$0400,$0400,$0400,$0400,$0400
data $0400,$0400,$0400,$0400,$0400,$0400,$08AA,$0000,$0000,$0000

data $0000,$0000,$0000,$0400,$0400,$0538,$0590,$0528,$0528,$0570
data $0468,$0540,$0528,$0508,$0520,$0400,$0400,$0000,$0000,$0000

...

screen_1:
data $3ABC,$3B3C,$3B3C,$3B3C,$3B3C,$3B3C,$3B3C,$3B3C,$3B3C,$3B3C
data $3B3C,$3B3C,$3B3C,$3B3C,$3B3C,$3AB4,$3200,$3200,$3200,$3200

data $3200,$3ABA,$3AB1,$3ABA,$3AB1,$3ABA,$3AB1,$3ABA,$3AB1,$3ABA
data $3AB1,$3ABA,$3AB1,$3ABA,$3AB1,$3200,$3200,$3200,$3200,$3200

...

screen_2:
data $3200,$3200,$3200,$3200,$3200,$3200,$3200,$3200,$3200,$3200
data $3200,$3200,$3200,$3200,$3200,$3200,$3200,$3200,$3200,$3200
 
data $3200,$3200,$3200,$3200,$3200,$3200,$3200,$3200,$3200,$3200
data $3200,$3200,$3AA4,$3B3C,$3B3C,$3B3C,$3B3C,$3B3C,$2050,$3B3C
 
data $3200,$3200,$3200,$3200,$3200,$3200,$3200,$3200,$3200,$3200
data $3200,$3200,$3ABC,$3B3C,$3B3C,$3B3C,$3B3C,$3B3C,$3B3C,$3B3C

...


    greenhead_games_map.txt

     

    I'm sure someone who knows what they're doing can come up with much better stuff than my samples, here.

    • Like 3

  15. Posted · Edited by Cybearg

    The irony is that, for what I'm doing, the sprites are easier to make and look great on the 2600 because they're more than 16 pixels tall and some have more than 3 colors each. While I plan to use the 7800 eventually, it might be actually more difficult to match what I want to do in some ways, this time.

     

    Thanks for the advice, folks. Appreciated. :)

    • Like 1

  17. Posted · Edited by Cybearg

    I've recently had a game idea that I would like to bring to the 2600. It strikes me that DPC+ would be able to accomplish my vision much better, even if it means that there could be no scrolling in the game (a fairly minor point for the design I have in mind, I think).

     

    I feel a bit torn, though; while DPC+ could meet my requirements more easily and would allow me to avoid using potentially annoying tricks like simulating 4 objects on screen through the use of flicker or having to deal with no_blank_lines, the price that DPC+ boards add to a finished product, plus the sense that using more modern technology like DPC+ is cheating and would be seen as inauthentic (and thus less desirable), are holding me back from jumping into DPC+.

     

    What are peoples' opinions on this? Is being able to work without minute flicker and a few other small niceties worth the +$10 minimum and the sense of "this couldn't actually have been done in the day..."?

  18. Posted · Edited by Cybearg

    I can't seem to get a non-flickering mess of an image when I combine the super chip's pfres (of greater than 12) with the pfheights kernel option. Am I doing something wrong or is there some problem I'm not aware of here? Is there a fix?

     rem batari Basic Program
 rem created 10/13/2014 1:34:20 AM by Visual bB Version 1.0.0.566

   set romsize 16kSC
   set kernel_options pfheights
   const pfwidth = 4
   const pfres = 18

 playfield:
 ................................
 .......XXX......................
 .......X...............XXXXX....
 ....X.XXX.X...........XXXXXXX...
 ....XXXXXXX...........XX.XXXX...
 ....XXX.XXX...........XXXXXXX...
 ....XX...XX...........X..XX.X...
 ....XX...XX...........X..XXXX...
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

 COLUPF = $0E
   pfheights:
   8
   2
   2
   2
   2
   2
   2
   2
   2
   2
   2
   2
   2
   2
   2
   2
   2
   2
end


title_loop

   drawscreen
 goto title_loop

    Removing const pfres = 18 or taking out the pfheights kernel option will both work, but otherwise it's a flickering mess.

    test_2.bas.bin

  19. Posted · Edited by Cybearg

    I've just tried this as well, with similar errors and no luck compiling the demo or my own attempt:

     

     

    [10/13/2014 1:00:07 AM] saving K:\vbB\projects\Grinch\test_pfcolors_with_pfheights_SC.bas succeeded.

    Compile started at 10/13/2014 1:00:08 AM
    Compiling K:\vbB\projects\Grinch\test_pfcolors_with_pfheights_SC.bas
    old value: $00a4 new value: $00a6
    old value: $00a5 new value: $00a7
    old value: $00a6 new value: $00aa
    old value: $00a7 new value: $00ab
    old value: $00a8 new value: $00ae
    old value: $00a9 new value: $00af
    old value: $00aa new value: $00b2
    old value: $00ab new value: $00b3
    old value: $00ac new value: $00b6
    old value: $00ad new value: $00b7
    old value: $00ae new value: $00ba
    old value: $00af new value: $00bb
    old value: $00b0 new value: $00be
    old value: $00b1 new value: $00bf
    old value: $00b2 new value: $00c2
    old value: $00b3 new value: $00c3
    old value: $00b4 new value: $00c6
    old value: $00b5 new value: $00c7
    old value: $00b6 new value: $00ca
    old value: $00b7 new value: $00cb
    old value: $00b8 new value: $00cc
    old value: $00b9 new value: $00cd
    old value: $00ba new value: $00ce
    old value: $00bb new value: $00cf
    old value: $00bc new value: $00d0
    old value: $00bd new value: $00d1
    old value: $00be new value: $00d2
    old value: $00bf new value: $00d3
    old value: $00a4 new value: $10d0
    old value: $00a4 new value: $10d0
    --- Unresolved Symbol List
    pfwidth 0000 ???? (R )
    FASTFETCH 0000 ???? (R )
    3623 bytes of ROM space left in bank 1
    2292 bytes of ROM space left in bank 2
    Fatal assembly error: Source is not resolvable.
    Errors were encountered during assembly.
    2600 Basic compilation completed.
    Compilation completed at 10/13/2014 1:00:09 AM
    view output file:///K:/vbB/projects/Grinch/bin
    Post compilation files deleted

    I'm attempting compilation through VisualBB. I'm using batariBasic 1.01dreveng36 and DASM 2.20.11 unofficial 20140202a

     

    It DOES create a .bin, but it's malformed and doesn't actually work.

    ASM_and_lists.zip

    test_pfcolors_with_pfheights_SC.bas.bin

    Also, will this work with a higher pfres?

     

    EDIT: I fixed the problem simply enough by just adding const pfwidth = 4, as per this post.

     

    However, pfres doesn't seem to work; I just get a flickering mess. However, that includes if I just define set kernel_options player1colors playercolors pfcolors pfheights normally, without using this minikernel. That somehow seems wrong to me, though. What am I overlooking here?

    test.bas

    test.bas.bin

  22. Posted

    When you say "nested procs," do you mean nesting the procedures declaratively, such as:

    myprocedureA: PROCEDURE

myprocedureB: PROCEDURE

END

END

    Or do you mean nested GOSUBS, such as:

    GOSUB myprocedureA

myprocedureA: PROCEDURE
GOSUB myprocedureB
END

myprocedureB: PROCEDURE
GOSUB myprocedureC
END

myprocedureC: PROCEDURE

END

    ?

     

    Because if the former, I don't know why you'd ever want to do that. If the latter, then you certainly CAN, but there are a limited number of nests you can call. If I understand correctly, each time a GOSUB is called, the current instruction address is pushed to the stack and the procedure's instruction address is called instead. When a RETURN is called, the previous address is popped from the stack and the code continues from where it left off. However, the stack is finite and can only hold so many instruction addresses, so you have to make sure you RETURN from your procedures or the stack will clog with addresses that never get popped back off.

  24. Posted

    Is this close to what you want or could it be modified to get what you want?

     

    randomterrain.com/atari-2600-memories-batari-basic-commands.html#playerscores_minikernel

    Almost! I do need a 6-digit score to be split into 2 and 4, though. If that could be modified to display a 2 digit score on one side and a 4 digit score on the other, that would be even better than I had hoped, since I could display the score at the same time!

     

    Is that possible and if so, how would one modify the minikernel to make that happen?

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...