Thomas Jentzsch wrote:
> I had a closer look at this version and had some
> problems with the tabs you're using. I had to correct
> the spaces myself. Could you post your settings or, even
> better, could you convert all tabs into spaces with the
> tabulator options of TextPad, please?
I'll do this definitely in the next version. This one wasn't done
<whisper> at home, I used some - uhm... 'free minutes' - at work
</whisper> where I was forced to use M$s Wordpad instead of my beloved
Textpad. This ruined the source even more than it already was :-)
> And it would be very helpful too, if you provide some
> cycle counting in your kernel.
That's harder to achieve. I myself have all instruction timings
memorized, so I can very quickly just count them when needed + This
kernel is 100% Try & Error, I didn't know how to do anything when I
started. So with all that Copy'n'Paste shifting instructions up'n'down,
it's hopeless from the start to do proper cycle counting + I'm
excessively using the trace function of Z26, when I'm really stuck
somewhere.
All I can offer is adding the cycles when I'm done, sorry.
> There's another free cycles if you avoid crossing a
> page at bne NextLine.
Hm... finally I get an idea, why the timing was ruined sometimes when I
was just adding variables in my initialistion code :-)
*HintNotedForLaterUse*
> I don't understand what you're doing with gunShift at
> the moment. Is it just dummy code now?
It's the halfway implemented gun angles which you are asking later for
:-)
In the meantime I completed that, using every free cycle left in the
kernel.
> > Ok, I didn't play all my jokers yet and maybe I'm able to get rid of one
> > or another CLC, SEC - or what I'm most positive about - the two EORs.
> Maybe (I'm not sure) I have another joker for you:
>
> instead of:
> CLC
> SBC verPosMx
>
> you could try:
> eor verPosMx
>
> This would save you 4 more cycles
Hey, that worked, too. Even with other powers of 2!
*HintNotedForLaterUseToo*
> At the moment you have a kernel where you are doing 4
> color writes and dis/enabling the ball and both
> missiles plus a HMOVE every line. And you're updating
> the graphics and putting new values into both missile
> moving registers every other line.
> The most time goes into the display of the missiles.
> I'm not sure, if this balance of used cycles is good.
> This would be not a problem for a demo, but it could be
> for a game.
You're absolutely right, especially with the beginning of the second
paragraph: "The most time goes into the display of the missiles."
I experimented some more and I could get that kernel working with very,
very brute force.
I could replace _all_ ($$$$),Y writes with $$$$,Y by pure RAM force.
Holding my three tables in RAM would free 6 cycles. So instead of just
changing the poiters I'd have to copy all three tables with new values
during VBLANK. Plus the 5 cycles you just gained me, plus 2 others I'd
gain by reversing my missile move logic. Would definitely make enough
cycles.
BUT: Those cycles would be spread throughout the kernel, it'd be next to
impossible to get that timed in less than 100 hours if at all. I just
refuse to do that :-)
So, coming to compromise. After a sleepless night, I came to a solution.
I think you'd come to the same solution regarding your brilliant, to the
point analysis: "The most time goes into the display of the missiles."
So the most gain / less lost compromise I can think of is:
FLICKERING GUNS
What do you think about that? I think it might just be acceptable. If I
get any midscreen repositioning working, I might even reduce it a bit so
it wouldn't be all permanent.
> I think, there is a danger, that your kernel gets to
> complex. Even a very nice and sophisticated kernel
> won't help much, if your game lacks gameplay.
> At the moment I'm missing things where the cowboys can
> take cover (like the big cactus in Outlaw).
Ok, the idea behind that was / is again flicker (From the beginning,
this time. No compromise here. It was planned. I swear. Ask Eckhard
:-)).
The kernel must be fully capable to display some different situations:
When having a Cactus:
Cowboy Cowboy
-------------NEXT FRAME --------------
Cowboy Cactus
-------------NEXT FRAME --------------
Cactus Cowboy
When having a Stage Coach:
Cowboy Cowboy
-------------NEXT FRAME --------------
Coach Cowboy
-------------NEXT FRAME --------------
Cowboy Coach
The cactus and the coach would be just cowboys without guns, speaking
from kernel sight. They'd just have different shape & color tables.
Again - with some clever repositioning it musn't flicker all the time.
What I have to consider is whether doing a cactus _and_ a stage coach is
a good idea.
A situation like:
Cowboy Cactus Coach Cowboy
Might blind your eyes with all that flickering :-)
I'll have to test that soon, since a centered catus/coach would be
easier to time I think.
Or, what do you think? Forget about Cowboys _and_ Cactus from the
beginning?
Hm... where are my calculations... A, here! I'd have to cycle the frames
like this:
0011
0101
1010
0110
1001
1100
No matter how you arrange it, you'd always have sprites blanked for two
frames, but the average display time is still 50% of the time...
Hm... hm... give it a try or not?
> And I also
> don't see how you'll be able to let the guns point at
> different angles.
At the moment the angle is fixed by shifts with +1 or -1 ($F0/$10 in the
kernel) I just made a variable out of that, to do variable shifts.
This, + alternating NUSIZx values + alternating ENAMx values (2/4/8 line
high guns) + differrent starting horizontal Missile positions,
definitely provide different angles. This will cause a lot of work
outside the kernel and a lot of precalculated tables, but in the end
it'll work out, I tested it :-)
> There just isn't enough time left,
> you already pushed the 2600 very nearly to it's limits.
Oh... I'll definitely try pushing it beyond it's limits. With that
missile compromise I just suggested, I might go where no 2600 programmer
has gone before :-)
> Please don't misunderstand me, you're doing a great
> job!
I don't misunderstand you at all, I think you just come to the same
conclusions as I do. Besides, you're doing exactly what I asked for:
commenting my kernel. So I've to thank you a lot.
> Just think about what your game should be.
Believe it or not, but I've 5 DIN A4 papers written full with the
complete design of the game (providing lot's of ideas & different
approaches in case some things don't work out). I'm not just porting the
original Gunfight, I'll try to add some originality here and there as
well. I had finsihed that paper before writing a single line of code and
it even contains plans for the sequel :-)
But right now, the display kernel has prio 1. Once it is finished and I
know it's capabillities and weaknesses, I'll think about game design
again. But feel free to contribute ideas any time, I'll add everything
to my Brainstorm papers.
Nothing will get lost, every idea is sacred :-)
Greetings,
thanks again for all your input & interest,
Manuel
-
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
