Jump to content

fultonbot

Members
  • Content Count

    489
  • Joined

  • Last visited

Everything posted by fultonbot

  1. 160A's I have dine adjustments for. However, 160B just feels so much more complicated. Here is a question: do I have to mention each alphacolor in the list indices? For example, if every palette has $00 as the alpha, do I need to do this: incgraphic steve.png 160B 0 1 2 3 0 4 5 6 0 7 8 9 0 10 11 12 where the "0" are entries for each alpha in each palette?
  2. So right now the inly issue then it figure out an pattern/method to approach getting the pallet colors correct So far I have not found one.
  3. Oh can you display 160B images on a 160A screen by specifying 160B when you load in the graphic?
  4. I did not realize until this morning that you could re-order the colors in the palette. Still some trial and error to match them to what the image has encoded too. 160B is a very interesting mode. You get two 12-color palettes? I could see some neat uses for a day-night game and stuff like that. -Steve
  5. Hi, playing with 160B and I have a question. In the image below, have you found the relationship between the colors in the painting palette and how they get indexed for display? Are the saved across, down, or in some other manner? Is it all trial and error?
  6. Oh thanks. Yeah, I'll take that advice and slow it down. I have the AtariVox voice saying those messages in my new build. It's a gimmick but it's fun.
  7. Oh cool, do you have a thread here for it?
  8. I'm using Atari 7800 Dev Studio with A7800 So right now I want to build a side-scrolling shooter. I started a bit here https://raz0red.github.io/js7800/?cart=https://intotheverticalblank.com/downloads/itvb5.bas.a78 But now I've gone back to find out the best mode and bitmap size to use to get the best FX. That's what these test are for. From what I can tell, using the character mode graphics is best for an adventure game where I want to check the values of distinct tiles but I don't need to perform explicit collision detection on each one. For a side scrolling game, it feels like 16 pixel zones are the best, with scrolling background made-up of wide (48/96pixels) bitmaps to allow for a maximum number of "sprites" on top without glitching out. Doublebuffering appears to really smooth things out. I'm going to keep that "topscreen" calculation in all my games, and when I see the numbers go from "0" to"1" (or above) I will know that things need to be optimized. My supposition is that any number above "0" is might be problematic, but no matter what, the game should stay at the same number the whole time to be consistent.
  9. A couple more questions. 1. Is this a good place to start to get a better understanding of all this?: http://7800.8bitdev.org/index.php/7800_Software_Guide 2. I'm wondering if need to get my tests onto real hardware to understand how things will perform. What is the easiest way to do that?
  10. Yes, exactly. Yeah, I know. This is actually not a game. I built a utility so I could push the display as far as possible in various scenarios and see how well it performs. As I'm watching the results. I have these questions. My goal is to really understand the trade-offs involved. It started with the save/restore. So you are also saying I should play with this and see the results too: set extradlmemory on ?
  11. no, this is cool! I'm not looking for rules. I'm looking for ways to understand. the three factors above help very much. So how does DMA time relate to refresh rate? Do they combine to make an effective frame rate? I've noticed that with 14x23 8x8 sprites with a zoneheight of 8, I'm seeing a "7" in my skipped frames calculations, but it takes almost a second to refresh the screen. From that I'd say the effective frame-rate is about 8fps. What am I missing? Sorry for being a dumbass on this. -Steve
  12. By limiting the displaylist (two 80x16 sprites instead of ten per zone) saved with savescreen I can now get about double the 8x8 sprites in a zone. It seems like there is a near direct relation to the number of sprites used in savescreen and the number I can get to display with drawscreen. I have not tried with doublebuffer yet. I will try the topscreen bit that looks useful. Another question: What is the relationship between the course characters drawing and the sprites. Is there a performance benefit to using plotchars to draw background than to use plotsprite? Thanks, Sorry for so many questions. I was in the middle of making a game, and decided to pull back and build some demo apps to see how to get the best performance.
  13. Wow! Yes, this is what I wanted to explore. So if I read that right, savescreen/restorescreen don't save/restore a bitmap. but a displaylist, so the way it's created could certainly affect performance. My guess is then, if I had a background made of wider (32-96 pixel) , 16 pixels high sprites saved to as a background, I'd see a performance boost. Would loadbanner help here too? Could I load a background that was 160x192 saved a single entry on the display list? That would probably slow everything to a crawl. Another related question. The doublebuffer function obviously uses some kind of system clock to calculation delta-time. Is there anyway to access this/ I want to display an FPS counter on the screen for my tests. Thanks!! -Steve
  14. I have a seemingly simple question. Does it matter how I build a bitmap screen before I save it? My test bed right now is zoneheight 8 to see how many 8x8 sprites I can get on the screen I created a background using 16x16 sprites and did savescreen There is a HUGE difference between the amount of 8x8 sprites I can get in a zone with and without a background I get about 5 with the background, and about 15 without the background Will I see a difference if I build the background using plotmap/plotmapfile or if I change the size of the bitmaps I used for the background?
  15. Hey, has there been any discussion or any announcements around Amico releases using the amazing, original art for the Intellivision games? Atari wasn't the only one with awesome box-art.
  16. Better games, Atari not low-balling developers for work-for-hire games, better devkits with more examples etc, etc,. etc.
  17. STV for "Steve", not SAF which were my actual initials. I still use those.
  18. Agreed. It's not bad. The developer appears to have put a lot of thought into it. I've only played once though, then continued my PES 2020 quest to win the Premiere League. but when that is done, I'll probably be back.
  19. I bought my brother a Jaguar in like 1996/97 under similar KayBee circumstances. They only had about 6 games, but I got everything they had. he still has it. It was just "okay", but couldn't even come close to matching my PSX with Namco Museum 1, Crash Bandicoot and Soviet Strike. It never got much play, but I think it had lots of potential. Tramiel Atari just did not care enough about video games to make it work (IMHO).
  20. I saw some Atari titles in the "retro re-imagined" portion of one of the videos. Besides Breakout, Pong and Missile Command, what else is being worked on?
  21. Good topic!! It was late 1991. I had pushed my Atari 1040 ST to the limit. I could only buy software at a store an hour away. I installed AT-Speed and was able to buy a few EGA an CGA PC games and run them on the ST. As I looked through the racks and racks of PC games at my local Software Etc. for CGA/EGA games, I noticed how many were then 256 Color VGA with SoundBlaster Sound: Wing Commander. Might And Magic III. Links. Falcon 3.0. Games only 2 miles away instead of driving 50 miles. For my birthday in 1992 my brother and I bought a 386-DX40, 4BM RAM, 40MB Hard drive, 56k modem.
×
×
  • Create New...