Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


DZ-Jay last won the day on December 30 2016

DZ-Jay had the most liked content!

Community Reputation

6,688 Excellent


About DZ-Jay

  • Rank
  • Birthday 12/13/1970

Profile Information

  • Custom Status
    The P-Machinery AGE is almost here!
  • Gender
  • Location
    NC, USA
  • Interests
    Music, books, video games, and programming.
  • Currently Playing
    Various Intellivision games...
  • Playing Next
    Some more Intellivision games...

Recent Profile Visitors

37,157 profile views
  1. Yes, if there is no other way to do so, I would consider it as well. The requirement in that case is to make the sprite large enough, which trumps it’s resolution. Actually, it can be very effective, although you do not get 8x16 hi-res sprites with background/software sprites. It is, if your game requires that many sprites. Another trade-off could be to reduce the number of objects and adjust the mechanics. I know of at least one game in which style and graphical detail were chosen over number of enemies, and it didn’t seem to have suffered much in the conversion. Thanks. Probably because it is not generic enough. It was used quite a lot because the animation was so good, but it wouldn’t apply to all games. Also note that there are slight variations in some of the running men of various games. One step at a time.
  2. That’s because you have not used them. For those who have, those lines and blocks can fill the edges of rather complex contours of more sophisticated graphics. You think geometric shapes = programmer art; but it’s not just that. Actually, quite the opposite. I first design graphics with custom cards, then I see which ones match closely to those in GROM and try to swap them. I also try to shift the pixels and align to the card boundaries to reuse cards as much as possible, while still giving a seamless and organic look. I do this until I reduce the GRAM count to a practical level. It’s not perfect, and there are plenty of other restrictions, but I categorically disagree with those who reject this off-hand with some assumption that one mode is “superior” to the other. They both have compromises, and they both have strengths, and they both can support very creative works in their own way. Take a look at an old thread where I was helping @artrag compose a 3-D looking title screen for Deep Zone. I never completed the work due to other priorities, but I got rather far, and what I came up with at the time was good, and was only possible in Color Stack mode using GROM cards. I still have confidence that I would have been able to reduce the card count to fit in GRAM by abusing the GROM even more and aligning the edges further to card boundaries. For other examples, dig up all the screenshots from GroovyBee’s announced but unreleased games. His pixel artist used Color Stack extensively in very impressive and colorful screens. No lines-and-patterns programmer art there, yet they use GROM. Perhaps.
  3. The question was whether the EXEC loads all those 16 GRAM cards at once and increases the pointer in the MOB’s A register, or does it just update the 2 GRAM cards for the MOB whenever the animation advances a frame? I believe the EXEC supports both kinds of animation, but I am not sure. dZ.
  4. Well, that would be an argument in favor of doing it by cycling the GRAM. Still, that cost doesn't come from the actual double-res MOBs, but from the implementation decisions. -dZ.
  5. Well, there is the fact that they take 2 GRAM cards. That's 16 for all 8 MOBs if you make them all high-res. It drops your GRAM budget from 64 to 48, which may or may not be an issue to a programmer. I personally always use 8x16 sprites and avoid magnification like the plague. I know that those big blocky pixels are a thing, but I don't like them. It's not impossible, but it does require some thought and planning in writing the code for it. Like you suggested, you would have to shift the pixels across multiple contiguous cards in the BACKTAB, which is not trivial. Cool! Nope, that's it: the cost is just GRAM. The STIC (video chip) will handle the display and resolution as normal and you won't notice it. Right-o! In fact, my game exploits this by dedicating two GRAM cards for each sprite and replacing them on every video frame, as necessary, depending on the animation rate. So the GRAM is constantly mutating to keep all animations fresh. It's still very fluid. Seq #8 - Twisted Toyland-iPhone.m4v Nice. -dZ.
  6. I recommend that you check out the demo "Inty-B Intro" that comes with the IntyBASIC SDK. In Windows, there is a shortcut to it in the Start Menu when you install the SDK. On a Mac, you can run it with the following command: intyexec intro It is a cute little tutorial made by @Tarzilla that shows you the features and capabilities of the Intellivision, including what you can do with sprites. The full code is included in the folder "Documents/Tutorials/Inty-B Intro" and it is written in a way that shows you how to do the same things yourself. All MOBs are a single color, but by overlaying them, you can make a logical object have multiple colors. I personally make a distinction between "movable objects" or MOBs (hardware), and "sprites" (logical game objects). In other words, you can make an enemy sprite, say, appear to have three colors by dedicating three MOBs to it, all aligned properly and moving in unison. It's a single logical sprite, because all three still represent a single enemy. Just like you can overlay MOBs to add color, you can put them together to make bigger sprites. Note that doing either of these will use up the MOBs, but sometimes that's what you have to do. If you want to use only one MOB per sprite, and you want it rectangular, you will have to magnify it vertically. This will make the pixels taller, so it loses resolution. As stated before, 8x16 sprites are built in. They use 2 GRAM cards, but by nature are at twice the vertical resolution than the background. That means that each of the 16 pixels tall, are 1/2 the size of a normal background pixel, so the 8x16 sprite looks 8x8 in size -- as compared to the background. This is a neat feature because it allows you to cram more details into normal-size sprites because of their higher resolution. (Again, check out the Inty-B tutorial, which illustrates all this in a nice Intellivision program.) So now, if you double it's vertical size, each of those 16 pixels will be the same height as a background card. It will then appear to be twice as tall as it is wide -- the same as 8x16 background pixels. That seems to be what you are looking to do. So to make a sprite like that, you need to: Define two GRAM cards for it, one for the top half, and one for the bottom half. Set it's vertical resolution to "double." Set it's vertical size to 2x. Take a look at the MOB Y Register layout again: We need to set the YRES bit to 1 (8x16), and the YSIZE field to 01 (full height). dZ.
  7. Yes. That’s why to me that is “double vertical resolution.” Magnifications is still “normal” (0), but the sprite has 16 pixels vertically for twice as much detail than background cards. It’s just a different way of looking at it. It may help others understand it as well.
  8. I agree, it’s just semantics. I just bring it up because it is easier to me to think of it that way, and weird the other way around; and I assumed (perhaps incorrectly) that I would not be the only one. Heheh. (There is an entire thread where this is argued, rather vigorously.) I remember the bigger sized rear wheels. I sort of always imagine F-1 cars like that; but those would be mostly for drag racing. Oh! Because of Bump N’ Jump, haha! True. (For a moment I thought you meant … well, let’s just say that I was imagining a rather wild track configuration somewhere in the hilliest parts of France!) Haha, yeah! Those look like trucks.
  9. That is actually 8 x 16, with double vertical resolution and double horizontal magnification. It takes two cards in GRAM, one for the top portion and one for the bottom portion, so vertically it is 16 pixels. Update: @carlsson beat me to it. Although I personally prefer to think of the vertical resolution as Single (1/2 pixel height) or Double (1 pixel height), rather than 0.5 vertical magnification.
  10. The timing is critical. The important point is to start as early as possible, and try to copy from left-to-right, top-to-bottom, to keep ahead of the STIC fetching data to build its frame buffer. One should be able to do this in pure IntyBASIC with a very tight loop. You could also leverage the SCREEN statement, which allows you to issue a window (i.e., a block or region smaller than the full area) of either the source or the destination. That's what the additional origin and offsets are for. The SCREEN statement is optimized for copying a block of memory. It's only drawback is that it has a significant overhead in setting itself up for the copy loop. The copy loop itself is very fast, but the initialization is a drag, making repeated use of the SCREEN statement within the same frame a bit fraught. For that you'll have to come up with a way to copy the multiple blocks progressively -- that is, ensuing that you are always copying the the rows from left-to-right, top-to-bottom, leading the raster scan. (I did some work on this for another project that required copying multiple regions of the screen at once, but it's all in Assembly.) However, for cases such as @Brian's Man Cave, where he only wants to copy one single block (i.e., the top portion of the screen, without the bottom rows), it should be perfectly adequate. -dZ.
  11. Yes, that's the point, I am. Sorry, I guess I was not very clear on that. I am using CART.MAC, which sets up a 42K memory map, and both versions of the game use it the same way. I have modified it slightly to support one dynamic ROM segment in the new game, that is only for bank-switching. However, I was expecting to bank-switch the others to page 0 for the new game, and some higher page for the new one. Yes. Oh, yeah, good point! Hmm ... I'll have to look into that. I agree, that is the question: if bank-switching is not allowed in any of the segments, I'll have to look into your other suggestion. Thanks for all the help! :) -dZ.
  12. Aren't the old addresses in the original game still valid, though? I mean, the CFG tells which parts of the binary to load to which segments, and the segments remain the same ... they are just in different pages. What I mean is, say the old game has an instruction that points to $2100. The CFG would have something like: [mapping] ; The new game maps ROMSEG 3 ($2000-$2FFF) to Page A $2000 - $2FFF = $2000 PAGE A ; The new game maps its own ROMSEG 3 ($2000-$2FFF) to Page F ; Only that its actual position in the binary is offset by ; the size of the new game. ; $XXXX = $2000 + word_size_of_new_game_rom $XXXX - $YYYY = $2000 PAGE F As long as the block within $XXXX - $YYYY is loaded into $2000 by bank-switching, all addresses in the game will still work, no? My understanding of the CFG mapping is that it takes the word position in the binary and maps it to a logical address space. The game code itself references this address space (not the physical position in the binary file). Is this not correct? -dZ.
  13. It looks like you are reading the wrong part of the screen data to update the new column. Perhaps you are still advancing the pointer instead of moving backwards when you change directions ... ?
  14. I've been thinking about this, and putting together in my mind all the notes on bank-switching and memory allocations scattered around, and I have a theory. Here's how I think this could work. Please let me know if this is wrong. Working on the new game code, I will add a menu selector in the $5000 address segment to switch to the appropriate ROM pages. The ROM segments in use by this program will be at page $0. I build the program into a BIN+CFG, which will include the mapping to the ROM segments in page $0. I then take the old ROM from the original game, and using the CFG file, adjust the address mappings starting from the end of the new ROM. These will map the segments to higher ROM pages. I then concatenate both ROMs together, the new one first, the old one second. I then add the adjusted CFG file mappings to the new game's CFG file. Does that sound about right? -dZ.
  15. This is what I am referring to. What is needed for it to work on non-Mattel titles? I thought I needed to know the offset of where the second ROM started and map its segments. I guess if the segments were padded to their boundaries it would be easier to find their offsets for the CFG address map, but on a pinch, I could write a script to compute that for me by scanning the listing file or something like that. But of course, I’m out of my depth here, so if I’m way off the mark, please tell me. dZ.
  • Create New...