| |
A bug, a feature request and an oddity Displaying 1-8 of 8 total.
1
dante-1
|
I just finished coding my leet object-oriented particle engine and noticed a few things:
BUG: image.Blit( x [integer], y [integer] [, translucency [boolean]] )
does not behave as expected. If you enter the 3rd parameter it does not work at all, and if you omit it it DOES in fact blend the images, although the documentation tells you the opposite.
REQUEST: As I see it there is currently no possibility to blit to an image. I guess that it's not too useful for most to do so, but I'd really appreciate it.
ODDITY: Since my particle spray detects when it is not passed an image and then uses single pixels and since my fps counter somehow works now I noticed that blending a 20*20 image with alpha (window.png to be exact) is FASTER than writing a single pixel on my machine. NOW THAT'S COOL ;).
PS: if anybody wants to see the particle code just say something.. here's the first line of the constructor of the main ParticleSpray class to whet your appetite ;):
def __init__(self,x=Random(1,800),y=Random(1,600),image=None,dir=90,dirdelta=0.5,speed=5,speeddelta=3,life=20):
Posted on 2001-08-19 17:04:00
|
andy
|
The translucency flag works, last I checked. If it's 0, then the image is dumped onscreen as it is. No blending occurs. If it's 1 or unspecified, then it blends it according to the image's alpha channel.
You passed over setrenderdest. ;) Look it up in the docs.
Pixel plotting is always slow. ^_~ But that is weird, since writing a single pixel shouldn't be faster than blending 400 pixels.
And that constructor won't do what you think it will. The default arguments are only evaluated once. x and y will default to some random value, but it'll be the same value every time the function is called.
"Ignorance is its own reward" -- Proverb
Posted on 2001-08-19 17:52:57
|
dante-1
|
Thanks for telling me about setrenderdest, I was just used to specify the destination in the function call from DDraw/Java2d.
Yeah I am aware of the fact that pixel plotting is slow when you do it on the gfx card, therefore I'll propose another flag which specifies wether to create a picture in gfx-card mem or normal Ram. (because some things (especially in 2D) can still be done better by the CPU)
I know that they are only evaluated once (as I said I read all the docs), and that's fine for me currently ;).
Regarding the translucency flag - Well, then the error is in the documentation °_°
Quote:
Blit() draws the image at the specified x, y coordinates. If translucency is specified and zero or is omitted, then the image is opaque, otherwise it's drawn translucently, and any pixels with a non-opaque (less than 255) value are blended with the colors it is blitted over.
And something else:
Are you planning to release some sort of spec for the v27 graphics dlls? I'd perhaps attempt to write a DirectX8 version.
Give someone a program and you'll frustrate them for a day,
teach someone how to program und you'll frustrate them for a lifetime.
Posted on 2001-08-19 18:17:17
|
andy
|
gfx_soft is purely software. I'm using DirectX only to set the display mode and dump stuff on it. When in windowed mode, the driver doesn't even use that, it uses win32's GDI instead. So... it's really, really strange that a pixel plot is faster than a 20x20 alpha blit. ^_~
Regarding the docs... um... oops. I'll fix that right away. Thanks.
There's no written-in-stone graphics plugin spec, due to my immense lack of organization. You could grab the source code, though. It's not terribly complicated.
You can grab the source at http://verge-rpg.com/~tsb/files/v27src.zip. There's also an incomplete OpenGL driver there, awaiting completion.
"Ignorance is its own reward" -- Proverb
Posted on 2001-08-19 20:06:32
|
dante-1
|
Well when it comes to GDI nothing can actually shock me anymore ;).
Btw, I used Maped for the last hour and decided that my first and only priority is to write a new map editor (if I find time to code anything at all).
It's not that it's that bad, it's just a bit "uncomfortable". (and it crashes whenever I try to load my PNG in a VSP)
I think VC++ is actually the worst tool to choose when it comes to programming anything that should even remotely resemble a GUI application ;). So, I'll look into the source, see if I can somehow figure out the .map and .vsp file formats and start to hack away using my lovely Borland C++ Builder 5 and the MFC-stomping goodness that is Borland's VCL :)).
If anything actually emerges from that effort it would surely benefit VERGE in that we would get a more user-friendly editor AND you'd have more time to work on the core engine.
We'll see.
(Btw: Before anyone gets his hopes too high, please note that I tend to lose interest in such projects in 1-3 months =) and then totally upset everyone by suddenly disappearing - so please don't count on me (but it could/should of course be different this time around))
Give someone a program and you'll frustrate them for a day,
teach someone how to program und you'll frustrate them for a lifetime.
Posted on 2001-08-19 20:38:06
|
dante-1
|
Here are two Screenshots (only ~80kb each so have a look):
http://members.chello.at/robert.thoman/various/verge/particle.jpg
http://members.chello.at/robert.thoman/various/verge/particle2.jpg
And here's the source (if you have any questions or REFs (requests for enhancements) / found any bugs please feel free to post):
http://members.chello.at/robert.thoman/various/verge/particles.py
Give someone a program and you'll frustrate them for a day,
teach someone how to program und you'll frustrate them for a lifetime.
Posted on 2001-08-19 20:45:54
|
dante-1
|
I examined the maped code and have to say that somehow, between the bits dating back to 99, the 3 different compression engines which are all still needed somehow and the use of a **** obscure String_k class (have those people never heard of the STL??!) I decided to rather write the DX8 library I had originally planned. (The gfx dll interface is really nice and clear, althoug OOP purists may be concerned about the amount of global functions ;).
Give someone a program and you'll frustrate them for a day,
teach someone how to program und you'll frustrate them for a lifetime.
Posted on 2001-08-20 01:04:48
|
andy
|
It turns out that DIB sections are pretty much ideal any time you're doing windowed rendering, since they don't depend on the bitdepth of the screen, and you get a direct pointer to their contents to boot.
Also, WinMapEd is coded in pure win32, no MFC involved. I will "relish" (read: suffer agonizing headache after headache) porting it to Linux. -_-;
string_k was a class aen whipped up. I'll replace it with STL, which I admit I should have used in the first place. There used to be an aen-written vector class in there too. <:D (which has since replaced with std::vector/list/queue)
I don't see any '99 code in here. O_o zlib.h is dated at '98, but that's not mine. Mikmod is second place, dated at december of '00.
The old RLE compression stuff is there purely so that I can import the old v2 file formats. The newer formats all use zlib.
Lastly, I'm looking forward to that D3D8 plugin. ^_^
"Ignorance is its own reward" -- Proverb
Posted on 2001-08-20 18:49:56
|
Displaying 1-8 of 8 total.
1
|
|
