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
