Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Cybearg

  1. Yeah, I was doing this, multiplying and dividing by tens, hundreds, thousands, and ten thousands across a number of print statements for each frame. The alternative, I guess, would be two 16-bit score values (since most scores are 6 digits long) to hold the value and then 6 8-bit score values to hold individual score digits to print?
  2. Hmm... I seem to be making some mistake with Color Stack mode. I define the mode like so: MODE 0, 0, 1, 4, 15 ... And then I print something: PRINT AT 101 COLOR 2, "Hello, World!" ... But the background becomes a different color than those specified by the stack. It seems to be directly tied to where I'm printing at, as 85, 101, and 117 all create a solid orange background, for instance. What am I missing here? EDIT: Apparently the problem was with using a PRINT statement before a WAIT after setting the MODE.
  3. Hmm... I've recently been experimenting with drawing the GUI and trying out screen scrolling, but after adding in screen scrolling and drawing the GUI, I suddenly have a significant slow-down on the emulator. I'm not sure if it's frames dropping due to too many cycles or some other oddity. If things start to seem to go slow, is that an indication of running out of clocks? I don't even have any game logic in place, so now I worry that I'll be walking on thin ice to keep from killing the processor.
  4. I suppose, as an alternative to floats, I could use 16-bit integers divided by 100 for X/Y coordinates, allowing me to use the 0-99 range as a decimal?
  5. Sort of. I have no idea how it was done. Clearly there's screen scrolling going on and the tennis court is a bunch of sprites, but how was the static board achieved? Or maybe there was no scrolling going on at that point and the background tiles were just playing a loop?
  6. What I had in mind won't work in the same way, unfortunately, as the game depends on the player reacting quickly to things that zip past, unless I rework the core gameplay to support static screens somehow...
  7. Wow, way to raise the freaking bar beyond reach! It looks absolutely amazing in every way! I'm so jealous...
  8. Ah, I see. That makes sense, albeit a bit disappointing. The game design I had in mind depends heavily on scrolling and there aren't the MOBs or card slots to spare for those tricks. It will either have to be crude scrolling for this game or a redesign of the core gameplay to something that scrolls between full screens, as with Legend of Zelda.
  9. What is the cycle cost of those extra GOSUBs? Is it essentially insignificant? By the way, what is a cycle exactly? Is it 1hz? The CPU that Inty uses is technically a good couple hundred thousand hertz slower than the 2600's 6507, yet Inty strikes me as having more processing power. Why is that, or am I just mistaken?
  10. Would it be inefficient to clear and redraw static elements each frame? For the UI, I'd basically have to write a full row and re-print each frame. For static elements like stars, I'd need to clear, check if the scroll covered them, and then draw each one by one. Are all of those peek and poke statements as inefficient as they sound?
  11. Could you maybe adapt the fixed point library that batariBasic uses?
  12. So if the TIA can pull off those awesome sound fx and music examples (throwing in Princess Rescue as another example), why doesn't everyone do it? What is the trick to making it sound great? Is it just happenstance, like these particular notes happen to sound good but most don't? Is there some trick to writing to TIA with raw ASM that gets more sounds out than BatariBasic or 7800basic can? Or is it a dithering trick of playing two sounds together or in rapid succession to give the illusion of another sound, sort of like how color dithering can imply more colors and shades than are actually there?
  13. Awesome! Will it be able to do speech synthesis, or is there a different module for the 7800 for that? Or would you just use an AtariVox?
  14. Thanks for the info, cats! That, with a bit of tweaking, worked great! Is there any way to limit which rows are scrolled when scrolling the playfield? I have some playfield elements (such as UI and things like the moon) which shouldn't be scrolled. I could, of course, print over them, but that's just a big waste of cycles. What would be the best way to go about this?
  15. I know that 7800basic has POKEY support (which seems like a must-have if you want your audio to be taken seriously), but will there be cartridges available for homebrews that include POKEY chips at reasonable prices? Also, I hope that the relative slowness of this thread isn't discouraging for you, RevEng. I'm super excited to try out 7800basic, but I've just taken a detour to IntyBasic-land to try a step up from batariBasic before another step up to 7800basic. Thanks for putting in all this work! I can't wait to get into the 7800!
  16. I saw this posted earlier and skimmed through it. Looks great! Thanks much for writing it out! I always wondered what IntyColor was for.
  17. Beat it, though it took me probably 30 tries at least. I haven't played it for the other levels to be honest, but the level design seems solid. As long as you keep getting good ideas, keep cranking 'em out, I guess. Does the entire game need to be completed in just those 2 lives, or is there a way to get more?
  18. Maybe I'm mistaken, but doesn't IntyBasic support Tiled for designing your screens? I'm not sure exactly how it works, but I thought I recalled reading that somewhere... If so, that might help you speed along the design process, if you're not already using it for levels. Also, for testing purposes, maybe there could be some way to key in the level one wants and directly jump to it as a debug mode feature, rather than having to play through the full game?
  19. Unfortunate, but gotcha. On a random note, does IntyBasic support floats? Apparently it supports signed and unsigned (though I'm not completely clear on how that works, either).
  20. Thanks for the info, by the way! A quick question concerning DEFINE statements: What does DEFINE do, exactly, that limits it to one DEFINE per WAIT? Doesn't it just poke a few bytes to memory? Could one work around DEFINE to set a number of random cards quickly by POKEing memory directly? If so, where would those memory locations be? At the beginning of the graphics space?
  21. I just now realized that you're programming with raw Assembly. Kudos for the effort, but I suspect that all of this could be done in a fraction of the time using IntyBasic.
  22. I'm wondering what is a proper expected game length as well, although I don't have even a single completed game level finished for anything--just thinking ahead. Unless there is some way to add save game support, like with the 2600's AtariVox, 30 levels seems more than enough, since it would have to be done in a single play session. About how long does each level take? Also, what is the maximum size for an INTV ROM?
  23. Is there any possibility of a kind of cross between this minikernel and the other one, so text can come from reusable sprites to reduce ROM, but it can handle more than just 16 characters?
  24. Do compilation carts like Piñata count? It should be coming to cart soon *looks uncertainly at Al*.
  25. Great to hear so many of my needs are in the to-do list. Another question (mostly one of practical advice): As you pointed out, the problem with those numbers were that it included the color. D'oh! With that in mind, what would be the most efficient algorithm for determining the card index of where a card intersects with a sprite? I've been trying this crude algorithm which is messy (as you see), slow, and inaccurate: temp1 = (((presX - 6) / % 20) + ((presY + 20) / 12) * 20 result = PEEK($0200 + temp1) / 8 Any suggestions from you more experienced coders on a better algorithm to account for converting the sprite's location to an index on an 8x8 grid? Ideally, accounting for near-hits and near-misses on both the right and left side of the sprite.
  • Create New...