Jump to content

DZ-Jay

Members
  • Content Count

    12,878
  • Joined

  • Last visited

  • Days Won

    21

DZ-Jay last won the day on December 30 2016

DZ-Jay had the most liked content!

Community Reputation

6,387 Excellent

2 Followers

About DZ-Jay

  • Rank
    Quadrunner
  • Birthday 12/13/1970

Profile Information

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

Recent Profile Visitors

31,522 profile views
  1. Any thoughts or comments on this topic? Anyone? ... Bueller? I expect to release the new version (revision #4) this week-end. There's still time to cram more stuff in it! :) -dZ.
  2. I managed to make a few micro-optimizations (both in size and speed) to compensate for the additional tests added in the last couple of enhancements. Yay! I'm preparing a new revision release for next week to include the optimizations and the new envelope backtracking. As long as I'm mucking about in there, if anybody has any particular enhancements they want to see, just post them here. I can't promise it'll be included this time, but I can at least consider it and add it to my TO-DO list. :) -dZ.
  3. @carlsson, I have a compromise for you: the backtracking offset is configurable globally. This won't give you the flexibility per instrument, as in #1, but it allows you to configure it per program, via a global constant. Plus, since it is subtracted from the end, it can be any value from 0 to 63. Not bad for a quick-and-dirty patch. :) -dZ.
  4. Hi, Geordie, I did not know the problem was so dire that it stopped you from submitting your game. :( Next time, if something like this happens and you can't find a way to solve it, just send me a PM and I'll do what I can. In any case, try to finish the game anyway and release it when you can. I'm sure it'll be equally appreciated by everyone. -dZ.
  5. @Arnauld, if you are around, I'd be very interested in knowing your thoughts on this. Not only on the possible solutions, but on the implementation above. @intvnut and @nanochess also, since they have contributed so much in the past. :) -dZ.
  6. Yes, I agree. I would love to implement #2, but I think I rather do it in a more holistic way than just hack the code right now to fix this immediate problem. My main concern is not only backwards-compatibility (like you said, there aren't that many songs out already, so it's not a big deal). My main concern is the cost in processing to handle it. I can work on that as a future enhancement with other features, like you have suggested. That's an idea.
  7. As for the implementation part, consider how the envelopes currently work: There is an 8-bit counter per channel that goes from 0 to 255, and is used to synchronize all effects on a note (envelope, arpeggio, vibrato, etc.). The counter starts at zero when a note starts, and increments until the next note, or the channel is silenced. The counter is adjusted depending on the speed of the envelope, each slower speed dividing the counter by 2. After adjusting the counter, the result is used as an index into the envelope table, which is packed 4-points per DECLE, one on each 4-bit nybble. After retrieving the appropriate word from the envelope table, the target nybble within the DECLE is computed as "Counter modulo 4." Note that a problem is is that the counter is for the entire instrument, not just the envelope. Therefore, we cannot just adjust it and save it; we have to account for an ever increasing counter. For instance, if I want to set a static backtrack offset of 8 (like IntyBASIC), I need to subtract 8 plus whatever overflow there is. This is the quick-and-dirty patch I came up with: ; Check envelope counter ; ---------------------- ; R0: Counter ; R1: Free CMPI #64, R0 ; Has the counter gone over? BLT @@env ; If not, process envelope normally MOVR R0, R1 ; \ ANDI #$3F, R1 ; > offset = (counter & 63) + 8 ADDI #8, R1 ; / SUBR R1, R0 ; counter -= offset ; Process envelope ; ---------------------- @@env That was just quick-and-dirty. Any ideas for improvement are welcome! -dZ.
  8. Reviving this old question about how to handle very long notes with fast envelopes in the Intellivision Music Tracker. To recap, the problem is that the tracker has no bounds checking in its envelopes, so if a note extends for too long, the envelope pointer will overflow to somewhere else in the data, which is most likely another envelope or trash. This is even more pronounced after I added very fast envelopes in the last tracker revision, which advance on every tick. I would appreciate if anybody has any suggestions on how best to resolve this issue. The problem can be split into two parts: First, there's the design component: how should the tracker handle very long notes? Should envelopes loop, backtrack, or just end? Second, there's the technical component: how to make this work within the constraints of the current implementation. For the first part, I can think of three possible solutions: Envelopes that include a backtracking offset, as suggested by @carlsson in the past. The idea is that when the synthesizer reaches the end of the envelope, it will use this offset to backtrack and repeat. This would allow for more flexible instrument design, but it may be over-complicate the implementation. It may also break previous songs. Envelopes that recycle automatically to a set point. This is what IntyBASIC currently does, which seems in tune with how real instruments work: once an amplitude level is reached, it is sustained until the note is released. This would be a bit less flexible than allowing arbitrary backtracking, but seems that it should be easier to implement. It would also be fully-backwards compatible with existing songs. Require very long envelopes, say 128 sample points instead the current 64. The problem is that envelopes require one data word per each sample point, so an extra 64 points will require 16 additional data words, per envelope. With lots of envelopes in use, this can get costly fast. I think #3 is not really an option. It is actually the way it works today (since the 64-point length is not enforced), but it leads to bloat. Plus, there is never a guarantee that a long enough note will not overflow the envelope. My experience suggests that this sort of problem is hard to identify. I think #1 is a good thing to have, but perhaps arbitrary offsets are not strictly necessary, and perhaps not worth the processing cost. After all, IntyBASIC proves that a static backtracking offset is perfectly adequate. Plus it sort of mimics the typical ADSR (Attack/Decay/Sustain/Release) envelope scheme, where the "Sustain" amplitude is maintained indefinitely until release. What do you think? Any feedback is welcome. -dZ.
  9. Cool. I personally would play Star Strike over Space Hawk any day of the week. -dZ.
  10. LOL! You can't tell from the angle, but that's actually only the side wall at the entrance of my living room. The deal I have with my wife is to just set up the retro video game center in that corner, and let the rest of the living room be our normal entertainment area. What you don't see is that opposite from that wall, there is a rather large entertainment area with a fireplace and all. That's were our regular big screen TV goes with all the modern trimmings -- including ... our Nintendo Switch and any other modern consoles we may get. So, that's just the "retro corner." Ultimately, the living room is split into two areas: the "retro" corner, and the rest. At least that's the plan ... -dZ.
  11. Hmmm ... decisions, decisions ... $20.00 ... or ... a $4.99 Worm Whomper?
  12. I don't have Spiker, sorry. But if Rev were to be nice to donate his copy to me, I'll definitely trade it. :)
  13. That's overpriced. It obviously costs only $4.99. That's my offer, @JasonlikesINTV: take it or leave it. -dZ.
  14. Thanks. Personally, I consider it a duty to offer helpful feedback to fellow programmers; and it is always an honour when my suggestions influence the game in some way. I know I can seem overly critical at times, but just know that all my comments are well intended, and come from my sincere believe that little tiny details can turn what is already a good game, into a great classic. You guys rock!!! Sounds great! There are also additional compression techniques that can be explored, especially when you are freed from the constraints of the contest and are able to use assembly language routines to accelerate or optimize performance. Wow, that sounds like ... an entirely new game! As awesome as that sounds, I would recommend leaving that for a subsequent release (Super Pro Pandora, Hehehe). I wouldn't want the project to stall by the everything-but-the-kitchen-sink syndrome. It would be a pity. That said, it sounds like an excellent idea to add re-playability to the game. I can't wait to play it later this week-end. 👍 Yes, I that would be best.
×
×
  • Create New...