Thanks!
I'm not sure - I've been thinking about adding other vehicles, or maybe leaving Outrun where it is and writing the Wolf3d style maze renderer!
I got sprite scaling working (but only 0.25/0.5/1/2/4, etc - using int scaling, as floating point is just too slow!). ...
I few pages ago I wrote some interesting texts (I hope so, at least) about
scaling using Bresenham's integer line drawing algorithm (Part 1) and later
showed how his algorithm basically computes a division (slope of the line) by
repeated subtraction. This intrinsic property of his algorithm is the reason
why it works for scaling as well, because we need to compute a division as
well when doing fractional scaling. I further showed in Part 2 how his
algorithm, now used for scaling, can be cast into a division algorithm based
on repeated subtraction. As a result, my algorithm at the end of Part 2 answer
the question when to drop and when to replicate pixels while scaling. It's
beautiful!
If you don't know about this already, you may like to read about those dirty
pixels of mine. xD
Part 1:
http://www.neogaf.com/forum/showpost.php?p=167307360&postcount=5176
Part 2:
http://www.neogaf.com/forum/showpost.php?p=167518422&postcount=5213
Now you may say;
"Wait, I need a 2d one!"
"And it should be all integer as well!"
Well, if we can replace one division with repeated subtraction, we may as such
replace another division by applying the same algorithm again, i.e. by
applying the algorithm I showed near the end of Part 2. Given the simplest 2d
floating-point scaler, we have two loops, i.e. foreach y { ... foreach x ...}
running over the destination image, and two divides (ratio=p/q, with p, q
integer). The inner loop over x and its ratio (srcX/dstX) can be replaced by
calling stretch_line_bhm. Ok. Now we are left with the outer loop over y and
its scaling ratio (srcY/dstY). This loop will be transformed into a repeated
subtraction loop of the same form as stretch_line_bhm itself, yet instead of
updating imgDst[x] = imgSrc[y], you call stretch_line_bhm.
I have it running; fractional scaling, all integer, and C code. Just a couple
of bytes. I could post the algorithm, but I won't -- at least not until you
tried yourself for awhile. I just don't want to spoil your party discovering
some of the things yourself. :+
And btw; Even if you start to make a Wolf3d, you will meet fractional scaling
again, if you want to have texture-mapped walls at least.
Holy shit, somebody is using our arts hahaha.
It looks great man! You using Unity for this?
also, by any chance, are you releasing any source code of these effects?
Seem like I should start to sell Unity effect assets. Aren't there many
already? However. Well, the code isn't that hard. It was just meant as an
exercise for the 1d scaler I've given away recently. It goes something like
this;
Code:
take two pix{1,2}
int y = 0;
for each column of the screen/window
scale column of pic1 into range [0, screen_height-y] and draw into
screen column of range [y, screen_height]
scale column of pic2 into range [0, y] and draw into screen column [0, y]
y++
If you increase y, pic1 will get smaller while pic2 gets larger up until you
hit the screen height where pic1 will be gone with pic2 fully scaled to the
screen height.
To get some cool effects you need to control y individually for each column.
I've set up a little data structure for each column to manage y. As you can
see in the animation, the columns do fall in an accelerated fashion, i.e. they
fall under gravity. Hence, y can be considered as a particle p with its data
structure containing stuff like the force due to gravity (or whatever), an
entry for the initial velocity etc.. The force then is two times integrated
to get the new position for y(t), i.e. p[x].y = 0.5f*p[x].f*t*t + p[x].v0*t
with f force, t time (with t0 = 0), and v0 the initial velocity. To make the
effect look the way it is, you just need to randomize the initial velocity
such that some column are more ahead than others when time starts.
You can tinker around with the initial velocity (take some cool functions
here). But the fun starts when you modify the force term, or define a whole
new function for p[x].y altogether. Of course, you have to take care of all
the boundary conditions!
How would writing a new operating system help him with this?
That's an insider.
