With large sprites you can reduce flicker significantly by combining the background redraw and sprite data in memory and write the lot to screen in one go. This eliminates the problem of writing to screen memory twice where the old and new sprite positions overlap.
Cheers Malcolm Phoebus R. Dokos wrote: > At 07:45 �� 19/2/2002 +0100, you wrote: > >> Marcel Kilgus makes some magical things to make me read >> } Phoebus R. Dokos wrote: >> } > So what I see is writing some sort of toolkit (a-la SSG) which >> can do this >> } > in high-colour (and more)... for example clever background >> redrawing of the >> } > screen on the anticipated movement of the sprite, >> } >> } This I don't understand. When doing sprites you only have to save and >> } redraw the part that is directly under the sprite. Why do you want to >> } predict where the sprite is moving to? >> >> Because he is taking the 'amiga/commodore' approach of game with sprite: >> he want the system to handle the graphic and the collision detection as >> well as (de-)synchronisation of the movements, >> thus leaving the game program with very little thing to do: >> managing the score and life counter, changing the level display,. > > > Well I wouldn't exactly call the logic of the movements or the > controls very little (especially in Shoot-em-up games) > But essentially you are right, it's exactly what I want to to do. > > >> IMHO, it's not the right approach. He should make his game without >> sprite, >> using instead 'Letter' and detecting collision in memory, not on the >> screen. >> Once the 'low-level graphic' works, he could replace it with all the >> fancy >> sprites he wants. In the mean time, he would have learned that he need >> to have the moving objects in memory, but also the full background, >> but not >> as a monolithic part, rather like an assembled puzzle. Thus moving a >> sprite >> is resumed to: draw the background where the sprite is (erasing the >> sprite), >> perform movement calculation, draw the sprite, wait for some event/time >> (or do something else somewhere else), do it again! > > > What you say doesn't negate what I want to do. > Indeed I do have the version that I want made character based and of > course I detect collision in memory not on screen. > Detecting the collision on screen is first of all extremely difficult > whenever thousands of colours are involved and very time consuming. > I separate the screen memory (well a mockup of the memory) in a grid > sized accordingly to the resolution used by the game and the maximum > sprite size (so for example for a res of 800 x 600 and 48x48 sprites > it's a grid of 16*12 (unless finer movement is desired). > All checks are made in that grid. > Additionally, yes I do know that and actually it's not that slow not > even in basic. What slows the calculation down is the conversion of a > linear data stream to places in the screen memory according to lines > (and those calculations take a long time in basic) > >> Problems unrelated to not having the sprite managed by a dedicated >> ship are: >> - The hero moves according to input stroke, unless input provide >> only a change >> in the direction of movement (the 'always-moving' type of pacman vs >> the 'one touch=one move' type of some other games). >> - The bad guys usually move in a kind of continuous ways, at least it's >> not like a chess game (bad guys wait for hero to move, then move >> themself, >> and wait again). So the management of the bad guys must be >> interlaced with >> the scanning of the input for the hero move. >> - collision between hero and bad guys: can happen when hero move, >> when bad guy >> move or when both move at the same time. Using letters to illustrate: >> >> ...HB... : hero(H) is just on the left of the bad guy(B) >> >> If hero move right, H & B are on the same cell, collision. >> If bad guy move left, H & B are on the same cell, collision >> if hero move right and bad guy move left, we end up with: >> >> ...BH... but a collision really occurs in the 'game logic'. >> This last case is the most difficult to detect. >> >> If hero move right and bad guy move right (at the same time), >> there should not be any collision (unless the hero is too quick !). >> >> - To add fun, the speed of the hero and the bad guy might be different, >> thus collision detection should use a finer grid and each object >> occupy >> more than one cell at the same time in this grid. >> >> Anyway, reading the screen to detect collision is just a bad >> approach, because >> it means that you are adding contraints to the graphical >> representation of >> your objects. It was the easy way with machine like spectrum and other, >> but it gives really bad habits and empeachs adaptation of the engine >> for >> other graphics. > > > True but see what I say above. All these are already done, but I am > afraid you misunderstood me too... > > > I seem to have a talent in being misunderstood lately... > > > Phoebus >
