Posted By
MMS
on 2011-09-03
16:58:33
 |  Great Giana Sisters
I was just surprised, how well the Giana Demo been converted with nice scroll.
Initially I was shocked, as on Plus4Emu (my definite emulator with Quality3 Display mode) the SID emulation was off, and music was just sound too good 
I doublechecked with YAPE, and yes, it is SID music.
In fact Plus4Emu 1.2.9 SID emulation is much nicer, closer to the real C64 sound than the latest YAPE, I dunno why.
The other thing I do not understand, why this demo got so low scores (AVG 5.0)? I think it was damn close to the original, and not too much needed to be a real good platformer for Plussy... So I woted an 8 now.
|
|
Posted By
Csabo
on 2011-09-04
10:37:18
| Re: Great Giana Sisters
The background and playing levels of the game can be converted with very little effort. It's just characters scrolling. The code is the same, only some registers and memory locations had to be changed.
Same thing with the SID music, it's more like a side effect that it still plays in emulators than a conscious effort on the part of the authors. The original code writes to the $D400 area and they didn't remove this.
When you said "not too much (is) needed to be a real good platformer"... nothing could be further from the truth! On the C64, the rest was done with sprites. The sprites' graphics is independent from the character set of course, and no effort is needed to "mix" them with the background. On the Plussy... Oh, do I even need to get into this? Basically massive code changes would be required just to display the sprites. Then you still have to write collision code, deal with color clashes, and the fact that a single 3x3 sprite takes up 16 characters from the character set - so the level graphics would have to be re-done.
So, to sum it up: releasing it like this is... well, almost useless. Maybe it's nice to watch the levels for a while, but you can't play. (And back in the day, you wouldn't have heard the music, my bet would be that the authors didn't know it was even there.) It definitely does not deserve a high score, I'd say even 5 is undeserved.
|
|
Posted By
MMS
on 2011-09-04
17:17:42
| Re: Great Giana Sisters
No, please do not explain software sprites too much. It hurts a lot
I know it eats up the resources, very complex.
Certainly I am not a good coder, etc, just commenting things, and argue with a good coder
On Plus4 there are still tons of games (also several converted ones) realized with character GFX, collision detection, etc, and they are not bad at all. Magician's curse for me a kind of etalon how to prevent color clashes. (no to speak about Spectrum, they have a different approach: they do not care at all...).
Some parts of GGS does not really need sprites (like Stage 2 and 4), due to the solid black background, so not too much color clash to be noticed. Bushes and mushrooms are a kind of headache on Stage1 and 3 --> kill them 
I agree with the comment on the high number of characters used up in case no sprites.
On the other hand just by swithing character set at a certain rasterline (one for the playground, one for the air with cloud, and one the bottom ground) you may have enough characters. Knowing, that C64 had double characterset due to inverted fontset (if I remember well)
The size of gamecharacters is a little problem here, I agree. But Invincible had much bigger ones, 48 pixels! So still Plus/4 is the winner, haha!
|
|
Posted By
George
on 2011-09-05
10:49:43
 | Re: Great Giana Sisters
I would like to hear about software sprites...is there a Doc or example for that topic fior the plus 4? I would like too write a little Space-Invaders programm for experimenting.
After playing "Starcross" from Infocom, which is great, i began to write a story for a new adventure.
|
|
Posted By
MMS
on 2011-09-05
13:31:56
| Re: Great Giana Sisters
Hi,
there are some very good threads on the topic, a deeply discussed source-code is available in assembly:
[ 1 ]
some suggestion how to do it in reality for action games:
[ 2 ] [ 3 ]
and some discussions explaining different approaches:
[ 4 ]
[ 5 ]
I hope it helps... I do mine in BASIC, haha! (but speed is not so important there)
|
|
Posted By
gerliczer
on 2011-09-05
15:51:41
| Re: Great Giana Sisters
Hi George,
The theory of softsprites is actually very simple:
1. Save the background where the sprite will be displayed.
2. "Mask" the background, which means to remove the content from the area where the sprite will be shown. It is done by ANDing the background data with an "inverse" sprite which is containing active (1) bits in the positions where there is no sprite graphic and inactive (0) ones in the others.
3. "Mix in" the sprite, which means to draw its content into the area cleared in step 2. It is done by ORing the prepared background with the actual sprite data.
4. Wait for the next display cycle.
5. Restore the background.
6. Repeat.
In plus/4 coding it works a little differently. Because of performance reasons sprites are usually coded for char screens, not for bitmap mode. First reason is that this way there is no need to store the original background. Actually it gets copied into the characters reserved for the sprite to be displayed, then gets treated as described above, and finally the characters are copied to the char-matrix. Second reason is that restoring the background requires only a small number of chars to copy.
Then there is the question of fine positioning of the sprite since the characters are quite large and movement would be rough and too fast otherwise. It requires to have more copies of the mask and the sprite for the possible horizontal sub-positions inside the chars, and the code must be prepared to be able to start its work in different vertical positions inside the character block of the sprite. (And there is animation, sprite priority and collisions too.)
But this is only my understanding of this technique. I never implemented this yet, only half of it in some experimental unlimited bob effect code.
|
|
Posted By
George
on 2011-09-05
16:02:20
| Re: Great Giana Sisters
hi gerliczer,
i understand the theory, but because i am not familiar with assembler code, i must see this at an example. I studied some of the code of the links of MMS. I became a smoking head. Too much input...
MMS thansk for the links
|
|
Posted By
Luca
on 2011-09-05
16:09:27
 | Re: Great Giana Sisters
After my challenging against charset based software sprites in Thalassa, in these months I added a little animated software sprite in bitmap environment to the cutey demopart I was coding (before real life hit me in the face, but I'm back now ), just because I got enough free rastertime. And from this experience, I learned this: unregarding how many times you face softsprites, they're a f*cking hassle every time, because optimizing them depends case by case, and to me Mike Dailly's job on XeO3 has something miraculous into it!
Lemme report a very nice forum thread on CSDb about that in general, have a look at the very last post.
|
|
Posted By
MMS
on 2011-09-05
16:33:55
| Re: Great Giana Sisters
Ha, in Basic is is simplier (or maybe looks like for an amateur, haha)
I just trying, that just put with GSHAPE the bitmap to the preferred place with a XOR, then I got a picture like with a sprite. When I want to move again, XOR again the same bitmap to remove it (restore original background) then define new position anx XOR it again.
Only problems:
-I am still not fully tested, how it will really work on multicolor GFX in all the cases. I am afraid I cannot prevent color clashes in this way, only in case sprite containy only Color 0 and Color3  then I am very much limited on the GFX color initial settings...
-GSHAPE is slow like hell. Austrospeed seems not turboing it. I will do a second trial with FOR and POKEs, maybe that is faster, but less "nice" code and nd more work from me. sih...
-I dunno if in assembly EOR can play the same role. Idea: EOR the bytes of your character to the bitmap. You have the spirte "copied". If you need pixel-fine movement, you may first EOR the bytes of the character again (remove it), then shift the character as much as you want (or use any of the previously saved position) and EOR it again. It is just theory...
|
|
Posted By
George
on 2011-09-05
16:44:50
| Re: Great Giana Sisters
Hi MMS...
i managed poking a dot from left to right....(Why did they make graphis so complicated?)
it was not very quick...for animation forget basic.
|
|
Posted By
MMS
on 2011-09-05
19:35:13
| Re: Great Giana Sisters
now writing from phone,bloody adsl provider.
So i tested eor/xor. So there are no color clashes,as poimter built up from color 0 and 3, but c3 part chamging it's color. On c3 backgroumd certainly becomes 0, but on c1 bckground becomes color2. Sounded to easy, and in fact it does not look sprite. But at least easy to do .
|
|
Posted By
George
on 2011-09-05
20:12:24
| Re: Great Giana Sisters
the ti 99 has a great basic!!!!
|
|
Posted By
MMS
on 2011-09-06
18:41:32
| Re: Great Giana Sisters
You surprised me! TI99 has sprites!
In fact C128 BASIC is up to that level, has everything Plus/4 or TI99 has, plus music, and memory banking, etc
Just a little slow
(for a long time I citized Spectrum QL SuperBASIC as one of the best implementation of BASIC, just by repeating experts like a parrot. today I read through the programming reference guide from the creator of SuperBASIC, It is very strong in I/O and database handling, and has some nice features like ARC and nice font feaures (underline, size, etc), Plus/4 has almost the same capabilities: everything, including window, graphics, special programming structures like DO UNTIL, etc. is available In fact Plus/4 has the GSHAPE to emulate sprite while QL can just copy it, but able to scroll and pan window too)
|
|
Posted By
MMS
on 2011-09-06
19:09:34
| Re: Great Giana Sisters
BTW I finished in BASIC the primitive sprite simulation: it works, no color clashes or recoloring. Follows the "big guys" advices: save the part of the screen (not playing any more with with XOR), and when I move, copy back the original bitmap then i copy the sprite to the next place.
Drawbacks:
-Bloody slow and blinking. On emulation 400% speed it is OK, but still blinking
-Only Color 0 and color 3 can be used for the "sprite", means only 1 colored sprite, no shadow or border.
-Translating it into kind of machine code and memory operation, it is exactly what experienced programmers suggested.
-I plan to check the same with POKEs how the speeds are comparable then, and Autrospeed TBC then
-Any comment how to improve it further is appreciated.
10 SCNCLR
20 COLOR1,1:COLOR0,2:COLOR3,3,4:COLOR2,8,5
30 PX=30: PY=32
40 GRAPHIC3,1
50 SSHAPE S$,30,32,40,42
60 DRAW3,30,32 TO 36,32 TO 34,34 TO 40,40 TO 38,42 TO 32,36
70 DRAW3,32,36 TO 30,38 TO 30,32
80 SSHAPE E$,30,32,40,42
90 GOSUB 500: REM DRAW TEST PATTERN
150 REM LETISZTAZAS
160 GSHAPE S$,30,32,0
170 GSHAPE E$,PX,PY,0
180 DO UNTIL I$="E"
190 GET I$
200 XO=PX: YO=PY
210 IF I$="Ý" AND PX>5 THEN PX=PX-5
220 IF I$="Ń" AND PY>5 THEN PY=PY-5
230 IF I$="ť" AND PX<155 THEN PX=PX+5
240 IF I$="‘" AND PY<195 THEN PY=PY+5
250 IF I$<>"" THEN GOSUB 280
260 LOOP
270 GRAPHIC0:END
280 REM SPRITE POSITIONING
290 GSHAPES$,XO,YO,0
300 SSHAPES$,PX,PY,PX+10,PY+10
310 GSHAPEE$,PX,PY,2
320 RETURN
500 REM TEST PATTERN
510 CIRCLE 3,100,100,35,70
520 CIRCLE 1,100,100,20,20
530 CIRCLE 2,110,110,20,50,35
540 DRAW 1,110,110 TO 125,125 TO 90,90
550 DRAW 1,120,125 TO 115,111 TO 80,75
560 RETURN
READY.
|
|
Posted By
SVS
on 2011-09-07
02:50:27
 | Re: Great Giana Sisters
@MMSZ
Be warned to the GSHAPE bug.
As I remember it affects the horizontal size of saved area.
|
|
Posted By
George
on 2011-09-07
07:08:06
| Re: Great Giana Sisters
A little faster.
10 SCNCLR
20 COLOR1,1:COLOR0,2:COLOR3,3,4:COLOR2,8,5
30 PX=30: PY=32
40 GRAPHIC3,1
50 SSHAPE S$,30,32,40,42
60 DRAW3,30,32 TO 36,32 TO 34,34 TO 40,40 TO 38,42 TO 32,36
70 DRAW3,32,36 TO 30,38 TO 30,32
80 SSHAPE E$,30,32,40,42
90 GOSUB 500: REM DRAW TEST PATTERN
150 REM LETISZTAZAS
160 GSHAPE S$,30,32,0
170 GSHAPE E$,PX,PY,0
175 XO=PX: YO=PY:
180 DO
190 GETKey I$
210 IF I$="A" AND PX>5 THEN PX=PX-5: GOSUB 280
220 IF I$="W" AND PY>5 THEN PY=PY-5: GOSUB 280
230 IF I$="D" AND PX<155 THEN PX=PX+5: GOSUB 280
240 IF I$="S" AND PY<195 THEN PY=PY+5: GOSUB 280
250 If I$="E" then GRAPHIC0: END
260 LOOP
280 REM SPRITE POSITIONING
290 GSHAPES$,XO,YO
300 SSHAPES$,PX,PY,PX+10,PY+10
310 GSHAPEE$,PX,PY,2 : XO=PX: YO=PY: goto 260
320 RETURN
500 REM TEST PATTERN
510 CIRCLE 3,100,100,35,70
520 CIRCLE 1,100,100,20,20
530 CIRCLE 2,110,110,20,50,35
540 DRAW 1,110,110 TO 125,125 TO 90,90
550 DRAW 1,120,125 TO 115,111 TO 80,75
560 RETURN
|
|
Posted By
Gaia
on 2011-09-07
11:48:43
| Re: Great Giana Sisters
You'd better forget about using GET/GETKEY if you want speed. Better use PEEK(196) to check key events.
|
|
Posted By
MMS
on 2011-09-07
13:06:40
| Re: Great Giana Sisters
Thanks for the hints! I will test them today evening (or tomorrow very early morning  )
|
|
Posted By
MMS
on 2015-08-31
16:12:18
| Re: Great Giana Sisters
Yeah, almost 4 years (!) passed since my last comment here, and started to code again my very old sweetheart project
Since my 4 years old post, I had 2 computer crashes, and some of my work lost, including this test code, several gfx, but can start with a fresh look
Some important changes since then:
-We found a new compiler, expected to support -in a certain way- the Basic V3.5, so will make a try.
- We have a great game (MOS) that has exactly the sprite limitations and wow as the one described below (color 0 and 3), and still look great.
Still the RS232 HW project (due to missing proper circuit and my laziness) still not finished, but decided to finish at least the documentation (partially destroyed on my DELL PC because of a crashed PSU died at a stormy night) and build in the "theretical" support of the HW mouse, OR you can simulate it by pressing the cursor buttons as per the below sample. The only disadvantage, that I planned to use mixed GFX and CHR screen, and the mouse emuation will not work outside the GFX screen (SSHAPE), and I designed the control buttons can be pressed to be in modified character set.
Just great how badly I planned the concept If I design the control buttons to be on the GFX part, then I need specific loader routine, or Loading + copy to GFX screen (damn slow in BASIC) and the LOAD can load a complete block of data without spaces.
The more I think about it, the more I like the idea of CS65 C compiler, BUT most probably there is NO SSHAPE and GSHAPE equivalent at all for Plus/4 version.
Bah, even BASIC is too complex for me
|
|
|
