Jump to content

Arnauld

Members
  • Content Count

    53
  • Joined

  • Last visited

Community Reputation

85 Excellent

About Arnauld

  • Rank
    Star Raider

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Paris / France

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I was half excited about it at the very beginning. I like the design of the console and the hardware seems OK, especially the controllers (assuming that they work as well as advertised). But I have basically no interest in the games, which honestly just look like something between Flash and low to mid-budget Wii or mobile games. I personally think that this 'low budget' approach would *not* be a problem if they had a pleasant retro feeling. Unfortunately, I haven't seen anything that caught my eyes so far. Also, I've nothing against the bring family and friends together again motto, but it seems like it only translates into "you're not going to see this or that kind of game on this system". I wish it was more like let's make cute and very simple games with top-notch gameplay again. I didn't pre-order anything, nor do I plan to buy the system anytime soon. I really hope that the extra development time will be used to improve the software and I do wish that the system will be successful enough to survive more than a few months so that better games have a chance to see the light of day. But right now, my expectations are very low.
  2. A popular and efficient shuffle algorithm is Fisher-Yates. It runs in linear time. (I'm using it for instance in Defender of the Crown to shuffle the lords at the beginning of the game.) Quoting the pseudo-code from Wikipedia: -- To shuffle an array a of n elements (indices 0..n-1): for i from n−1 downto 1 do j ← random integer such that 0 ≤ j ≤ i exchange a[j] and a[i]
  3. If you really just want a hint: there are 60 VBL interrupts per second on NTSC systems and 50 VBL interrupts per second on PAL systems. This is actually not 100% accurate and will diverge slightly. But it should be good enough.
  4. Thanks for sharing this. It's great to see an enhanced version and I'll definitely give it a try when I have a chance to.
  5. In Burger Time, there are 2 MOBs for the chef, 2 MOBs for the egg and 4 x 1 MOB for the hot dogs and pickles. Because the pepper is also drawn with a MOB and all MOBs are already used, the yellow part of the egg is borrowed when the pepper is used.
  6. This is how I used to start the game as a kid. I don't remember the next moves, though.
  7. Every once in a while, I post an answer in CP1610 assembly on codegolf.stackexchange.com. I'm usually doing that for trivial challenges that would be boring to solve in some higher level language. The following challenge was recently posted (slightly rephrased): Given three positive integers (a, b, c), write a program or function that determines whether any triangle could have (a, b, c) for side lengths. I thought that you guys might be interested in giving it a try. My solution (spoiler) is a 12-DECLE routine taking the integers in R0, R1, R2 and setting or clearing the carry. To be honest, I didn't spend a lot of time on it so it's quite likely that a shorter solution exists. You can follow this link to see more of my Intellivision answers on Code Golf if you're curious.
  8. The differences between 2 consecutive frames are pre-computed at build time and stored as bitmasks representing the cards and rows to update, followed by the graphics data. Storing the full frames and computing the differences at run time would require more storage and -- first and foremost -- much more CPU time.
  9. It's not Rick Dangerous anymore, as we can't use the original title. But you should hear about Rick Dynamite in the near future.
  10. A somewhat less obvious but quite impactful limitation is the number of cycles during which the CPU has access to the STIC and the GRAM. As a programmer, I think I'll put that one at the top of the list as it often leads to impossible or complicated situations. For instance, in the kiss scene of Defender of the Crown, I had to use self-generating code: at frame N, the program generates the code that will be used to update only the GRAM rows that actually need to be updated during the next VBLANK for frame N+1, because we don't have enough time to update the full cards. As a game designer, I'd probably say the number of sprites. But it really depends on the game type.
  11. I actually started to write a new version doing exactly that some years ago -- except it was using the CC3 at that time. But part of the source code was lost when my laptop was stolen and I got somewhat demotivated. It turned out that the serial connection was very instable with my 50Hz console and I had to add some kind of error correction code (I don't remember the details, though). Here is a short video showing data being transferred from the PC after the fix was implemented.
  12. That's correct. This is the MiniGame Compo version which was released in a rush. It doesn't perform any initialization of the STIC registers, so jzIntv cannot be blame for that. I believe that the state of the STIC after reset is pretty much random on the real hardware as well when the full EXEC boot sequence is bypassed.
  13. For what it's worth, below is the scheme I'm using in a few projects. Each command is 8-bit wide, so each word contains 2 commands. Note that this version assumes FG/BG mode and doesn't support GROM cards apart from the blank one. It also relies on the assumption that the order of appearance of new GRAM cards is sorted. It would definitely require some tuning to support any background scene. nnnnn001 -> draw N+1 blank cards, using the background color nnnnn101 -> draw N+1 blank cards, using the foreground color nnnnnn00 -> draw GRAM card #N nnnnn010 -> draw the next N+1 GRAM cards (e.g. if the GRAM index is currently set to 7 and N = 2, this will draw cards #7, #8 and #9 and update the GRAM index to 10) nnnnn110 -> repeat the last GRAM card N+1 times (NB: blank cards may have been inserted in-between) -nnnn011 -> set the background color to N 1----111 -> end of image 0-nnn111 -> set the foreground color to N
  14. Yes, it does require extra RAM. I don't think that 20 kB is much of an issue for modern boards. If you were to store the uncompressed raw data in ROM, it would be about 285 kB for Chambers of Shaolin -- which would probably be more problematic. That said, I fully agree with you: tracker based music is the way to go. This YM project was more of a fun hack and a way to demonstrate the capabilities of the Intellivision PSG when pushed to its limits. And incidentally, the vast majority of tunes available today in YM format were originally generated with trackers (like these ones).
  15. Quite a lot, actually. As described above, the sliding windows require 10 x 1K-word (20,480 bytes). The space occupied by other variables is negligible.
×
×
  • Create New...