Silk Worm: WIP!

[Heaven/TQA]

Rybags... why do the plus4 need to move the entire screen at once as the TED can softscroll, too?

[Rybags]

I was referring to the character /chunky scroll movement itself. TED has the 2K aligned screen origin, so no LMS tricks. Fine scroll is same as C64, 0-7 pixel offset.

 

It can do similar "DMA Delay" type tricks as the C64 for finer control of the screen origin but I don't think Xeo3 does that.

 

Looks like development of that game has stopped - nothing new for over 3 years.

Edited December 11, 2011 by Rybags

[emkay]

The game isn't in bitmap mode, as has been pointed out probably 3 times already.

 

Scrolling DMA loss can be lowered by using HScrol values C - F.

 

Sticking to bitmap mode would be the solution for the A8... for this game.

 

Why?

-> Just because of the nº of Chars used in the game map?

-> Because of more chars need for the shifting of sprites?

-> Because of more cycles cost in soft sprite?

-> Because of PF2&PF3 colour clash?

 

OR:

-> All combined?

 

All combined fits good.

 

Back to the main point.

Silkworm uses more , bigger, and more different enemies, and XEO3 is already fiddling with the available cycles.

Using PM with DMA isn't the "final solution", as there is DMA used, even when not needed, and it doesn't exchange "8" software sprites into 8 hardware sprites.

[TMR]

It can do similar "DMA Delay" type tricks as the C64 for finer control of the screen origin but I don't think Xeo3 does that.

 

No it doesn't, VSP scrollers are fairly easy to spot because they "lose" the top character line of the screen for the routine. But the load for scrolling can at least be spread out over multiple frames whilst the smooth scroll does it's thing, so there's not a huge eight hundred plus bytes crash dump between buffers happening once every eight frames.

 

Looks like development of that game has stopped - nothing new for over 3 years.

 

It's gone quiet because Mike Dailly's working for what was only a start-up company a few years back - he's doing work code and that's all he gets time for right now. A pain in the arse for those of use who have been waiting for Xeo3 on the Plus/4 and indeed C64 for quite a while, but i'm sure most of us understand...

[andym00]

For the record, Xeo3 runs at 25fps on the Plus4.. It'd be a kindergarten port for the A8

 

(null)

[emkay]

For the record, Xeo3 runs at 25fps on the Plus4.. It'd be a kindergarten port for the A8

 

(null)

 

 

I'd really like to see a real description of how the Plus 4 TED works.

 

As it seems, it is able - similar to VICII - to use RAM on the other half of a "clock". Which means it should read and refresh RAM without cycle stealing .

 

Taking care of the "2" badlines" every "charline", it shouldn't be that much.

Edited December 12, 2011 by emkay

[Rybags]

It doesn't.

 

The similarity to VIC is with the attributes. The similarity to Atari is the clock speed and cycle stealing for any access it needs to make.

 

The "other half of the clock" re TED refers to the "slow mode". You can run the Plus4 at half clock speed via a TED register setting. When TED does cycle stealing, it does so by putting the CPU into a "long cycle", but the net result is same as Antic does, just a different methodology.

[andym00]

TED is described fairly simply here..

http://mclauchlan.si...king12/gfx.html

 

Character modes need $800 bytes of RAM for screen and color memory. The first $400 bytes act as color memory (the memory permanently located at $d800 on the C64), with the lower 4 bits containing color codes, exactly as found on the 64. Bits 4-6 denote the intensity level of the color, while the high bit select flashing/no-flashing attributes. The other $400 bytes contain the screen codes for the displayed characters. If hardware character inversion is selected, the lower 7 bits hold the screen code and the high bit selects inversion for the character. If character inversion is not selected, all 8 bits denote the screen code. Extended Color Mode (ECM) and Multi Color Mode (MCM) modes work exactly as described on the 64. While these two modes are in effect, inversion and blinking are disabled.

 

edit: And the thing to realise with the 64 is the the colour memory is on it's own bus internally to VICII, so it can read one colour byte per cycle without using the main memory bus, which on a badline is saturated with graphics fetches and character code fetches..

TEDs colour RAM is in main memory, hence needing 2 badlines to fetch all the data..

[sack-c0s]

rather than have all these issues with the Atari charset and switch to bitmap mode, has anyone tried writing a map compiler which scans the tilemap and works out which tiles can be reassigned?

 

You'd just step through the map from left to right, and allocate every visible tile you hit to a char up until the limit you specify. if that limit is exceeded on a single screen then an error would be flagged up in the map compiler.

 

It would then step through the new columns of data that would scroll on from the right and if it had no free chars to assign it would find one that wouldn't be on screen at that point and flag it for reassignment, ideally choosing the one that it least likely to reenter the screen in the short-term.

 

The heavy lifting could be done by a chunk of C/python/<insert language here> on a PC, and it would spit out a worklist for the Atari, which it would just blindly follow. Because the PC is doing all the work upfront you can also extend it to do other things, like spread the tile reloads across frames to balance the work the A8 has to do, or optimise the amount of reloads required.

 

It would make using the tilemap for collision detection a bit more work (unless you used the top bit of the tile number for that), but it might save a lot of overhead of trying to haul bitmap data around memory.

 

The technique would work for all machines that use a char/tile system, but I think it'd particularly benefit the A8.

Edited December 12, 2011 by sack-c0s

[Rybags]

Sounds like a good technique.

 

But is there source/doco for the game available?

 

By the sounds of it, the game stalled on Plus4 but must have developed further along on other systems.

[José Pereira]

rather than have all these issues with the Atari charset and switch to bitmap mode, has anyone tried writing a map compiler which scans the tilemap and works out which tiles can be reassigned?

 

You'd just step through the map from left to right, and allocate every visible tile you hit to a char up until the limit you specify. if that limit is exceeded on a single screen then an error would be flagged up in the map compiler.

 

It would then step through the new columns of data that would scroll on from the right and if it had no free chars to assign it would find one that wouldn't be on screen at that point and flag it for reassignment, ideally choosing the one that it least likely to reenter the screen in the short-term.

 

The heavy lifting could be done by a chunk of C/python/<insert language here> on a PC, and it would spit out a worklist for the Atari, which it would just blindly follow. Because the PC is doing all the work upfront you can also extend it to do other things, like spread the tile reloads across frames to balance the work the A8 has to do, or optimise the amount of reloads required.

 

It would make using the tilemap for collision detection a bit more work (unless you used the top bit of the tile number for that), but it might save a lot of overhead of trying to haul bitmap data around memory.

 

The technique would work for all machines that use a char/tile system, but I think it'd particularly benefit the A8.

 

Remember Edge Grinder? That's the way to go.

Popmilo talked with me he was thinking doing exactly like that.

I have to ask if he did anything...

Edited December 12, 2011 by José Pereira

[sack-c0s]

I remember mentioning the idea before (possibly on formatwar), but I still think it's worth a try. I keep meaning to add it to my mastersystem scrollcode, but I'm a bit tied by the amount of bandwidth you have to the damn TI videochip...

[Heaven/TQA]

what would be the benefit? does it not make things more complicated than the 3x approach?

[José Pereira]

what would be the benefit? does it not make things more complicated than the 3x approach?

Popmilo saw that even one Charline as one charset from the begining untill the end of Edge Grinder Map you have more than 128chars (even without soft sprites).

The idea is that it is useful to many more games.

Edited December 12, 2011 by José Pereira

[sack-c0s]

what would be the benefit? does it not make things more complicated than the 3x approach?

 

I'm not sure about the relative complexity to be honest - I think the only way that one is getting answered is to hack it together and see how it turns out. Having charset zones across the screen would lead to duplication of characters if the same thing could appear in multiple zones of the screen, so it could end up using more memory possibly?

 

I dunno... It's swings and roundabouts and probably varies on a map by map basis...

[Rybags]

I was checking the Xeo3 blogs yesterday.

 

Consider the 10 or however many softsprites - there's potentially 9 characters each there. Player ship can be PMG so make that 8 or 9 softsprites, either way it's still more than half the character set.

 

Zones would be necessary - chances are there's probably never more than 5-6 enemies in a 3 character zone, but even that eats a lot of characters.

 

Xeo3 would probably best be done as a "forked" project, if it was possible to pick it up. Use the stuff like scripting / enemy movement engine. Rework the rendering so multiple chsets are catered for. Probably expand the level scripting so that dynamic character reassignment can take place.

 

Of course the memory size problem rears it's head. The obvious cure from the start is to do the thing either for large RAM systems or put on a 1 Meg cart.

[Tezz]

This is the method I am using in the demonstration that I've been working on the past couple of weeks.

[sack-c0s]

are they the same enemy onscreen, and are they in a similar sub-character position? if so that could give you a saving if you mapped things out carefully. Would probably be incredibly restrictive though

[Rybags]

I think the enemies present are same for the most part.

 

Counting on them sharing pixel offsets would work some of the time, but then they'd also have to be in blank space. Not worth the bother I reckon.

 

Plus it'd probably mean simplified attack patterns. One of the outstanding things of that game from the Plus4 perspective is the way the enemies move.

 

You could say that for Atari too - give them simple straight attacking lines and it becomes just another lame shooter.

[José Pereira]

That Level1 (the only one available) it's 504chars: XEO3 chars.zip

[José Pereira]

what would be the benefit? does it not make things more complicated than the 3x approach?

 

Thre's most of the times a need for that.

For example XEO3 even in 1charline=1charset we would need that.

Top Level1 Map charline has 121chars:

Edited December 12, 2011 by José Pereira

[Creature XL]

what would be the benefit? does it not make things more complicated than the 3x approach?

 

Thre's most of the times a need for that.

 

There is most of the time need for that when you cover a game from another computer.

This way it is correct.

 

If you make your own levels you can make them in a way that it fits in the available chars

[andym00]

That Level1 (the only one available) it's 504chars: XEO3 chars.zip

 

IIRC, I think it used a flipped charset for the bottom half of the screen.. On that level at least..

 

In my tests I did originally with looking at doing Xeo3 on the A8, I think I came up with 270 chars in total, which was easily splittable between 3 charsets that dynamically copied in characters through a simple runtime reference counting system which releases a char into the free pool when it leaves the left side, and allocates and copies a new one when we add it to the right, which adds nothing to the actual complexity, beyond a a few arrays to refcount, store forward and backward mappings without any need to preprocess the map.. Except for an absolute pathological worst case of 168bytes if every character is new, but then that time is split over many frames anyway..

 

I honestly don't see what's stopping this happening on the A8.. The Plus/4 is slower (1MHZ with all DMA time and slow/fast cpu switches taken into account) than the A8 at this, and none of the Plus/4s colour features are being used, it's nothing by a 4 colour character screen.. It's having to move the entire screen (1K) every few frames which you can do via LMS magic and not have to move anything around in memory, it's running a SID music player as well (50FPS?) for the music (and we all know how fast those aren't), and a separate 2 channel SFX driver on TED sound. And even then the game is still only running at 25FPS at the end of the day.. The A8 should be able to absolutely ace this in 64K, and still have time to waste.. In fact, I would have thought the only major issue would be if it can actually be done at 50fps ?

 

I don't even think it's a particularly good game personally, but as someone said earlier it's better than most of the other shooters on the A8 because stuff doesn't fly in a straight line, yet from a technical point of view I think it's not actually that good.. I'd suggest looking at the 64 version, and use the sprites from there with player underlays.. Hell, it's only a max of 10sprites, not even a big multiplexer..

 

Bloody hell, I sound like you know who now

[Eagle]

Let's do simple math....

 

10 softsprites 3x3 chars

 

Forget the loop, change page, memory addressing postindex, etc..

Simple lda $xxxx,x sta $xxxx,x etc.

For the purposes of example.

 

10 sprites * 9 chars = 90 chars

90*8 bytes= 720bytes

 

than you need copy to buffor this chars

 

f.e. simple (no loops)

lda ,x - 4cycles

sta ,x - 5cycles

 

9 cycles * 90 chars = 810 cycles

 

we need back buffor to screen

next 810 cycles

 

copy data from chars to buffor

 

lda ,x

sta ,x

9 cycles

 

720bytes * 9 cycles= 6480 cycles

 

after this we need put enemies

 

f.e. (no loop)

lda ,x - 4

and ,x -4

ora ,x -4

sta ,x -5

 

17 cycles

720bytes*17 cycles = 12240

 

All 20340 cycles !!!

 

Not calculated addresses to copy.

There is no loop. There is no post indexed addressing.

Together with this we will need a minimum of 2 times more.

 

The logic of the game takes also much time.

 

f.e.

 

Collisions. For every missile fired. Checking of the 10 objects.

Minimum 70 cycles for 1 objects.

700 cycles for 10 objects in best case scenario

 

And what about the trajectory of moving objects?

If you want to do double buffering, we need have two times more charsets.

And at the end. Opponents of the size of a 8x16 will not look good.

Not everything is as simple as it seems.

 

Eagle

[Heaven/TQA]

Ok. Can someone please describe me the char alloc system a little bit more in detail? 3 zones right? And you are looking at the level map which virtual char needs to copied at a free available char per zone while then put on the right side where the virtual would appear?