Jump to content

Cybearg

Members
  • Content Count

    951
  • Joined

  • Last visited

Everything posted by Cybearg

  1. After expressing my concerns about ROM space, I have added a COMPRESS option to export compressed map data, like so: I also applied a number of bug fixes, so it's worth getting this version. IntyMapper_1.2.zip
  2. 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.
  3. What about page flipping in IntyBasic?
  4. 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?
  5. 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. 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. 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. Wish someone had told me that before I made a program to help me to exactly that. 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. Exactly. 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. 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: 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. I guess I was fortunate in that I was using a super high level language and have the luxury of coding like a slob.
  7. 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?
  8. 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. Odd that I can't edit the original post anymore. I could have sworn I used to be able to edit long after the fact... Anyway, I've made the grid and clear button additions you requested, freeweed. Additionally, I added undo/redo buttons to make things a bit easier to work with. IntyMapper 1.1 here: IntyMapper.zip
  10. If you mean drawing with tiles and it spits out the formatted screen data, then yup! 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?
  11. I should have done this in the first post, but here are some screenshots and examples. SpriteAid IntyMapper Color Stack Mode sunny_day.csv.txt Foreground-Background Mode 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.
  12. I can't really say I understand what it's for or how it works, but awesome! It sounds like a sort of IntyBasic, except with a custom-built, object-oriented language.
  13. Well if you have any cool tools of your own, I'd love to see 'em shared! I was surprised that there wasn't already a map editing tool for Intellivision, unless one DOES exist and I just didn't hear about it.
  14. Since I'm lazy, I made myself a little program called SpriteAid for configuring IntyBasic sprite options and another, bigger program called IntyMapper to allow me to visually draw out screens for IntyBasic. I'm sure both programs are a bit buggy as I'm a very inexperienced programmer, but hopefully they will be useful to someone besides just myself. Enjoy! IntyMapper.zip SpriteAid.zip
  15. By block, I assume you're referring to the way that functions in C languages are like boxes stacked within boxes? There's a bit of that with procedures in BASIC, right?
  16. Cybearg

    Compromising

    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.
  17. Afraid not. Someone else had the same problem as me, but there are no solutions brought up there, just people acknowledging the problem. I guess that means there's no option for it.
  18. 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..."?
  19. 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
  20. I've just tried this as well, with similar errors and no luck compiling the demo or my own attempt: 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
  21. Awesome, thanks! Now to try getting it to work...
  22. 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.
  23. Yeah... The problem comes in the sacrifice of pfheights for pfcolors. If only there was a way to sacrifice the ball or something for the ability to use pfheights and pfcolors together.
  24. 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?
×
×
  • Create New...