Quote:
|
Originally Posted by meynaf
That would require a new thread, if not a whole site !
Basically, it's making an open, lightweight, efficient, cool to code, computer architecture, which remains in adequation with todays requirements.
Remember : architectures persist longer than implementations.
The machine has to be some sort of "generic box" like PCs are meant to be.
It must be user friendly as well as programmer friendly, like Amigas are.
I am unsure an Amiga board is the right place to discuss of this.
|
Yes, it is quite off-topic! But a discussion could go in the off-topic section. Basically it's the ot-stupidity forum where all the silly stuff goes, the ot-general section should do fine!
Quote:
|
Originally Posted by meynaf
|
Yes, I've read it, and there are some mighty strange things happening. This really deserves a closer look.
Quote:
|
Originally Posted by meynaf
Yeah, learn i386 assembler, and see its beautiful syntax, its numerous general-purpose registers, its powerful addressing modes...
See how it's easy to bang on the hardware, how well it is documented...
See the poetry of the various memory models...
|
They've done it for linux/windows (and 4gw, if I got the name right) etc. If they can do it, then so can I
Of course, it won't be pretty. And that's probably an understatement. I still want to get into this, sooner or later, so I'm just going to have to cope!
Quote:
|
Originally Posted by meynaf
Good. I'm sure you feel much better now.  |
Yeah, man, I should've done this way sooner
Quote:
|
Originally Posted by meynaf
For 2x2 you basically make an average with :
. 9/16 of current pixel value
. 3/16 of left or right pixel value
. 3/16 of top or bottom pixel value
. 1/16 of diagonal pixel value
|
With diagonal I suppose you mean x+1,y+1, where the current pixel is just x,y?
Quote:
|
Originally Posted by meynaf
How would a bilinear filter do that ? (you have 1 pixel and want to output 4)
A box filter would simply copy them around ; not good.
|
If I've got it right, then this code should do bilinear interpolation for 2x2:
Code:
For yy=0 To 511 Step 2
If InKey$<>"" Then Stop
For xx=0 To 639 Step 2
xxx=xx\2+640:yyy=yy\2
p1=pointg(xxx-1,yyy-1):p2=Pointg(xxx,yyy-1):p3=Pointg(xxx+1,yyy-1)
p4=pointg(xxx-1,yyy):p5=Pointg(xxx,yyy):p6=Pointg(xxx+1,yyy)
p7=pointg(xxx-1,yyy+1):p8=Pointg(xxx,yyy+1):p9=Pointg(xxx+1,yyy+1)
p=(p1+p2+p4+p5)\4:plot(xx,yy+512,p)
p=(p2+p3+p5+p6)\4:plot(xx+1,yy+512,p)
p=(p4+p5+p7+p8)\4:plot(xx,yy+1+512,p)
p=(p5+p6+p8+p9)\4:plot(xx+1,yy+1+512,p)
Next
Next
Of course, this is freebasic. Pointg is a procedure that simply returns the gray value for an rgb pixel. And plot writes a gray scale (0-255) pixel to screen. Then the image which has to be interpolated is located at 640,0 and is 320x256 gray scale pixels. The interpolated result is located at 0,512 and is 640x512 gray scale pixels. At location 0,0 there is the original which is scaled down. Of coarse the down scaling is not in this code. The \ is simply the same as /, except that \ does not round after dividing. I sure hope that's all clear...
Quote:
|
Originally Posted by meynaf
Feel free to do whatever you wish. 
I don't have Dice or VBCC, and I don't like SasC's command-line stuff.
However I have StormC, maybe not the latest version, but I may look if I can do a project file, so you can compile the project.
The jpeg library compiles litteraly everywhere, but linking with asm (especially mine ) is something else (I wouldn't try this with gcc).
On the other hand you can simply disable the jpeg support and assemble the program (you would notice a major exe size drop then). |
I would really appreciate it if you could do a Storm project. I have Storm 3, should be good enough, right? It would really be nice if I can compile the whole program as a simple Storm project; it would mean that when I find some optimizations that I can actually test them, instead of guessing if it's going to work or not. Not being able to run tests, just plain sucks, as you know. Again, if you could do it, then many, many thanks
