Hello everyone I''m a novice programmer on the PC-Engine console and also novice in general programming. PCE is a 1987 console and have a really slow CPU so programming (in C) needs to be a minimum optimized and I can''t put too much * or / and better use << and >> etc... Well, I now try to make a little shooting game and I need to move a sprite from A(xa;ya) to B(xb;yb) with a constant speed. For example, it could be used to be the path of a bullet fired by an ennemy to my ship. But I can''t use real vars xxx,xxx doesn''t exist, so y=Ax+B is impossible I made a program which works well with a bresenham algo but it''s perhap already too much calculs I''s not important that the bullet EXACTLY reachs xb;yb if it goes the good direction it''s already a lot ^.^ If you can help me, feel free to mail me at pckid@free.fr or post here. Thank you PS: if you''re interested by PCE programming, go to www.zeograd.com

OH MY GOD!! PCENGINE game programming,, and with C?? i have to check that site now!! cant believe it!! YEAH!!

"Those who follow the path of the warrior must be ready to die, to stand for their convictions, live for one´s convictions, die for one´s convictions"

quote:
I made a program which works well with a bresenham algo but it''s perhap already too much calculs
I''s not important that the bullet EXACTLY reachs xb;yb
if it goes the good direction it''s already a lot ^.^

Have you thought about using fixed point numbers?

IIRC, the PC Engine''s CPU was a derivative of the 6502 which means it is 8-bit. I''m not sure how well the HuC compiler deals with large data types (such as 16 or 32 bit), but my guess would be that you shouldn''t rely on the compiler too much.

If possible, use assembly. If you''d really prefer to stick to C, try making a 16-bit data type and use it as an 8.8 fixed point number (the high 8 bits can be your integer position, the low 8 bits are fractional.)

Actually, you might be able to use integer coordinates for the missile but use an 8-bit fixed point number to do the updating. You could have a 2.6 or 3.5 fixed point number (which would only allow you to move a maximum of 2 or 3 pixels per frame, respectively.) Maybe 4.4 or 5.3 would be better -- it all depends on how much precision you need.

Try to look up a tutorial on fixed point numbers using Google if you don''t already know how they''re done.

---
Bart

You might want to look at pattern based plotting, you hard code the pattern that repeats for a line at a known slope.

If you have a resolution of 256 x 256 and plot lines from 0,0 that end at 256,y for as many angles as you want to calculate. (Where y is a value starting at 0 and then increased by interval you choose.) Looking at these lines plotted you can see there is a pattern that is 100% predictable and reusable. Using the patterns for angles over 45 degress of arch is all you need. The rays extending in directions other than what we pre-plotted are the same patterns but with the signs altered accordingly. If we apply a fixed interval of 4 for our y cord we get 64 patterns we can hold in an array used for generating upto 256 different rays extending from the same point.

Now that is only part of the puzzle, the other part in finding out which pattern is the one you need to track a path from one object to another. This can also be partly pre-calculated and only require tests done with simple/fast math to find which to apply. I belive I''ll let you figure that out on your own.

The best part is that it can all be done as fixed point addition and subtaction, which is fast on an 8bit processor. Even faster performance is possible if you know how to do it in assembly and limit operations that require you to fetch vaules outside of the registers.

*Shuns fancy floating point math*

Thank for replies, I''ll try all this