Cybergoth
-
Content Count
10,869 -
Joined
-
Last visited
Blog Comments posted by Cybergoth
-
-
Hehe... I'm not that quick downloading things. (Especially when I'm still at work
) -
The flickersort routine is now uses almost all of the vblank area, so let me know if you see any screen rolling.One tip I have is ending the VBLANK timer like this:
LDA INTIM BMI TimerExpired BNE WaitIntimReady RTS TimerExpired BRK
A bit brute force, but you *will* notice if you exceed VBLANK time
-
Blood clots can cause sudden unexpected death.Did she take the anti-baby-pill for many years? Possibly combined with smoking?
This seems to be an incredibly dangerous mixture for women
-
Andrew Braybrook was one of the most talented programmers in classic gaming history.
Yup. Too bad his games never made him big money, so he's working for an insurance company these days
He also wrote Paradroid and Uridium.Those will be covered in my next two entries
I spent well over 100 hours on each of those three games.Hm... I never had Gribbly, but the 100 hours for Uridium may be close. Paradroid though... I think it would be a lot more than 100 hours. Maybe 500, maybe more. In fact to this day, I never really *stopped* playing it
Gribbly's Day Out is among my top 10 all time favorites for the C64 ... I'm pretty sure there's a trainer version of this game out there.I just checked, but unfortunately neither a Remember nor a Nostalgia version is availabe. Maybe some day in the future?
Greetings,
Manuel
-
I bet you a dollar that you and your kids will have the most fun playing "Sky Diver"
-
1
-
-
It also sucks that on my Namco P'n'P stick Bosconian has totally ruined controls, not allowing diagonal movement.
-
Bosconian is one incredible well designed game. It's really a shame that it never got any real ports back in the day.
This is a really well-thought concept for a 2600 conversion. I always love to see the clever ideas "art"-people come up with to make it around the 2600 limitations. Like all the cool stuff retrofan was posting for a while.
Sometimes it really helps to have an artists vision of a 2600 version, as it may focus on totally different aspects than a programmers vision.
-
Eh, came in too late anyway
-
I loved the box for Space Instigators. I think VHS boxes like that should be very affordable as well, especially since they should still be in mass production.
-
Hehe, you can always send Marble Craze to StanJr and get your money back
I can't play it either. As soon as the protective walls are gone I'm lost
-
Thanks for the kind words!
I attached the raw data in case someone is interested. Currently it is 896 bytes, it'll be very interesting to see how much the new driver will reduce it
I'm planning on a little overhaul for the whole SID2TIA package, so that it'll help create tune data for the soon to be written TSM 4.0 driver
First thing I'm going to write is a bunch of WORD macros
to speed up the *manual* part of the data preparation. But I'll also update SID2TIA itself, to procude some slightly different raw output. -
Hi there!
From the old source code:
; Alien Sprites are 8 Pixels High (+ 2 Pixel Gap ???) sbc #8+2
So are you absolutely certain that you only loose 2 scanlines inbetween 2 sprites? The Gap should match the the minimum number of lines you're needing inbetween, they sorta add up to a virtual height.
In Star Fire and C7 I lose 6 scanlines each, so adding just 2 seems a bit low to me.
-
Anyway, I need to start working on getting that Helium Heroes patch... I'm a long ways away from it....if it ever sees the light of day...
-
Hm... most of the time a scale of
would be good enough for me Thanks for the CB 4/5 as well. I'd even rate Star Fire 4/5, my favourite is still Seawolf. Not only was it the most fun to write, I also still enjoy playing it myself
-
Hi John!
A puzzle for you
Do you think 4A50 would allow doing something like this:
The three circles of football helmets rotate to the left and to the right independently. The color schemes are hardcoded as is. It works breakoutish, so individual helmet-ball collisions checks would be required as well as the removal of helmets. Also the ball must be able to freely roam the whole area.
See a way for coming close?
-
Hmmm... all 5 out of 5 so far! Can that possibly continue?The next check is already in the mail
Thanks a lot, I'm glad you like my efforts so far
-
Looking at the Colony 7 code, it appears that the selection of the next sprite to display is performed by the following codeYup, that's it. It's a very brute force approach as I have a very special case here, with the engine only tracking 6 objects.
The problem I see here is that this can only cope with 6 sprites within the same horizontal region? For example, if you have 8 sprites in the same region followed by some sprites in a lower region. The first pass through this code will select the first sprite from this list, and the second pass through will select the sixth sprite from the list (by default). However, as this region will have already been displayed on the screen, the sprites in the lower region will not be displayed, or am I misunderstanding the code?Well, in this special case, you're absolutely right. (Only difference is that the first pass is already done outside the kernel.)
But some things to consider:
- Is 6 sprites in a row really a desired state of the game engine? It should be absolute worst case, and you'll rather want to avoid that by movement schemes / AI.
- supercat posted some very tricky improvement of the code somewhere, resolving the worst case somewhat, so it might be able to perform 7, 8 or more checks in the same time. (I'd estimate in the end your engine will be able to run 8-12 sprites at max, depending on the time your object handler consumes)
- After some 4,5,6 skips you could check wether you already found a displayable sprite - and if not, you run a second iteration of the scanning code.
Another issue that I am having with the flickersort routine concerns the movement of sprites. In Juno First, the sprites wrap-around so that when a sprite disappears off the top of the screen it reappears at the bottom (and vice versa). The problem with flickersort is that it assumes the sprites are roughly ordered within the list. However, this will not be the case when a sprite wraps around the screen, and it may take many passes through the flickersort code before the sprite is moved back to the correct position again. Putting the sprite directly in the correct position could require shifting all of the other sprites within the list (worst case), which doesn't seem like a good solution. Therefore, I think the only solution is to use a circular buffer, with a movable pointer to the beginning of the list, though this will porbably mean that I can only have a maximum of 16 sprites or the calculations will get awkward? Has anyone found a better solution to this problem?The two options you found sound both very good to me.
I sort of have a third in Star Fire, but I'm not sure if/how it's applicable here:
Since the absolute vertical region is a lot bigger than the visual region, I always spawn ships in *behind* the player. So by the time you manage to scroll them into the visible area, they've already been sorted into place
-
Well, for one is a list of objects sorted with Flickersort never really sorted, and then it'd also depend on wether the actual bullets are done with the multiplexing engine as well or rather with particles.
Also, even this small snippet is 200 cycles already for 20 objects.
-
Oha... can't take any credits here. The tune was composed by Peter Clarke and the visuals were programmed by Piero Cavina
-
I like your suggestion for combining the index array and the index pointer - I would have never thought of that! At first I though this would require more memory, but then I saw the light I will try to implement this in the next version as it should save a few cycles and possibly allow me to avoid tearing on the missile sprites.It should use the same amount of RAM. I didn't tell you that in my example because I thought it might've been confusing, but of course INDEX may already be the first byte of INVS, as it doesn't matter if you overwrite it after the frst sprite is drawn.
Greetings,
Manuel
-
Thanks for looking at my code - it is always useful to have an extra pair of eyes looking for optimisations.It's an excellent way to *warm up* - so I'll be ready for C7 soon again
I hope my code didn't scar you too much, as things are rather messy in there at the moment
It's a whole lot more commented than most of my stuff, that surely helps. Also you do an incredible amount of accurate cycle counting, which looks a whole lot better than my usual try'n'error chaos
The grid lines would have to avoid the lines where the next sprite is selected. You will have seen how difficult it was to do this already for the repositioning lines! Also, this would require more gaps between sprites, i.e. more flicker.That is true. It increases the virtual height of a sprite and you're forced to skip sprites that could've been drawn because they are detected too late, both of which increase the flicker. I improved this from Star Fire to C7.
In Star Fire I could test the next two sprites per 2LK iteration. In C7 it is granted that I find the next sprite within one single iteration. Of course C7 only tracks 5 objects at a time
If I remember correctly from Colony 7, you are limited to 4 sprites in the same horizontal band. I though it would be difficult to ensure this in Juno First?No. I think you're mixing this up with either Leprechaun or one of Johns ideas he posted regarding Bobs Demon Attack experiments. My approach will secure equal distribution of on-time regardless of the number of sprites.
I haven't measured the cost in cycles yet, but there seems to be plenty of spare cycles remaining and I haven't started using the overscan region.Like I told Bob, don't underestimate the object handler. It's an absolute killer task: Collision detection, movement, AI, spawning logic, etc. - for each object!
Also I'd estimate you'll need at least two more variables for each sprite. Hm... ok, then you'll also have to reduce the number of objects... always tricky to find the right balance
Also, I suspect that it will be possible to combine the flicker sort and index creation, but I wanted to check that they worked properly first.That is a good idea!
I'm not sure what you meant by the following. I don't see how you can load these immediately without using self modifying code, but I could be missing something?Oh, sorry, I should've given an example. I meant once you advance to the next sprite, you could possibly do something like this:
dec INDEX
ldy INDEX
ldx INVS,Y
lda INVY,X
sta TEMPY
lda INVX,X
sta TEMPX
lda INVT,X
sta TEMPT
So from then on you can access all data straight through TEMPY, TEMPX, TEMPT without having to deal with the index again until the next sprite is to be drawn.
-
Hi Chris!
I'm studying your source for some time now, and one thing I noticed is that you're creating an extra index of displayable sprites.
That seems to have advantages and disadvantages.
The advantage of course, inside the kernel you no longer need to check wether your sprite is displayable or not.
The disadvantage is that you loose cycles each time you need to access your data inside the kernel. You need extra RAM and a significant extra amount of time for creating the index.
One idea I had, was to store INVT, INVX, INVY immediately temporary, so that you only need to load once via index.
The second idea was that you not just DEC your INDEX, but *update* it. You just get the next INVS value and store that in INDEX.
That can either be via an extra counter, or by building your index table a little different:
Assume 4 sprites. Assume you want to draw 1, 4, 2 in that order.
Then create an index like
INVS = 1, 4, FF, FF, 2
Start with:
LDA INVS
STA INDEX
Then advance to the next sprite with:
LDX INDEX
BMI Done
LDA INVS,X
STA INDEX
Done
Still... I think doing without an index is always the better compromise. Especially in this case, when the Flickersort will have to swap all values anyway...
Hope you don't mind. Just food for thought to inspire you. Maybe it frees some cycles for the HMOVE or the particle thing
-
Anyway, I don't know how I missed this.Probably because Glenn posted the Origami entry only a few hours later.
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Dawn Elizabeth Payson--May 16, 1971 - Mar 29, 1999
in 2600 in 2006
A blog by supercat
Posted
Does a span of 7 years have any deeper meaning, like in a cultural or religious context? Just asking, because you said you'll try and find a wife now.
I can't imagine what you must've gone through in those years
I couldn't imagine being a single day without my wife or daughter anymore.