| |
Are there any plans to use hardware acceleration features? Displaying 1-15 of 15 total.
1
blues_zodiakos
|
I ask this because some of the blitting functions (mainly rotscale) seem ExTrEmElY slow, and could probably be sped up emensely by drawing them as textured polygons. I realize that that introduces an entirely new set of problems. :D However it might really be worth it.
Ignore this completely if they already are using textured polygons with D3D8+. I know that DX8 combined Direct Draw and Direct3D, making it difficult to combine 2d and 3d stuff at the same time unless you are drawing everything as textured polygons, or simply using DX7 interfaces for all the 2d stuff.
Also, are there any plans to expose the streamed audio buffer? So we could make a parser that would responds to beats? Yes, I know that's crazy. :D
Posted on 2004-03-07 10:19:50
|
vecna
|
Its not high on the list. The video system is setup so that other drivers can be added, but in my limited understanding of how these 3d apis work, the way the v3 graphics api is constructed is not particularly suitable - eg, for a graphics accelerator, there IS a difference between the screen buffer and just any texture, its not just another image object. Im sure its possible to simulate but I believe much of the speed would be lost when rendering to non-screen surfaces.
In any case... There's certainly room to optimize the blitters that exist before moving to a 3d accelerated api. And that option is a possibility regardless.
As for the streamed audio buffer.... uh, well, that seems a bit silly. ^_^ I've seen a few threads on BPM detection from an audio stream and such while checking out the FMOD forums and the code looks pretty nasty, I dont think its something you'd really want to do in VC. Probably a much better solution would be to use get pattern/row commands on a module, which is planned.
Posted on 2004-03-07 15:31:21
|
blues_zodiakos
|
It would probably be much easier to just sit down with a pad and pencil and make checkmarks everytime you hear a beat, and simply program the times in by hand. I had to entertain the idea regardless. :D Anyone ever played Rez? It's my hero.
Posted on 2004-03-07 16:37:51
|
grenideer
|
DX8 has a sprite library which is designed for 2d graphics. Each sprite still has its own texture buffer but you can blit them to the screen and perform many cool effects on them (including rotation) really easily. Rotation is generally pretty slow, I think.
I kinda got lost and missed what you were saying about 3D apis, vecna. Probably cause I have no idea how v3 handles graphics. D3D keeps a screen buffer (or two, or three) and texture buffers are basically pointers to chunks of memory on the video card (when resident) or to your slower computer RAM (when not).
Still, v3 isn't a 3D engine so it seems overkill to include 3D acceleration.
Posted on 2004-03-07 22:17:32
|
andy
|
3D APIs currently have lots of idiotic restrictions on textures. For instance, the dimensions must be powers of two. (ie 16x32, 256x256, etc) Also, older video cards (pre-TNT2ish) can't deal with textures bigger than 256.
As vecna said, the framebuffer is not conceptually the same as a texture in the eyes of most video hardware. You can pull from the framebuffer, and you can draw to it, but you can't draw polygons directly on a texture. (you can draw to the screen, then copy that to a texture, though...)
The other big caveat is that the pixel format in the image itself is stored in the format that's most convenient for the hardware, not you. (this only really matters if you're doing pixel-by-pixel image operations, though)
The upside, of course, is that mediocre 3D hardware can outpace any software renderer ever written without significant effort on the part of the programmer. You also get a lot of image transforms effectively for free: Quake 3 renders thousands (millions?) of arbitrarily distorted, tinted, and textured triangles every second.
As I understand it, v3 is aiming for relatively low-powered hardware (P2ish?), so ultrahigh resolutions aren't a high priority. At 320x240 and the like there are few enough pixels that it's not unfeasable to operate on each one every retrace.
(by the way, OpenGL 1.5 adds non-power-of-two-sized textures and superbuffers, which solve the render-to-texture conundrum. It's just a matter of waiting for video card manufacturers to make compliant drivers)
Posted on 2004-03-07 23:56:57
|
blues_zodiakos
|
My real reason for bringing this up is that I ran into this problem the other day: I was trying to make a rotating ground plane for my battle system (to SIMULATE the effect of a camera rotating it's X axis) by drawing a rotated sprite, and then scale blitting it to the bottom half of the screen. It worked fairly well, until someone pointed out that the there was no perspective being shown, aka things farther from the camera should appear smaller. I was going to add a few scaled layers to create this effect (similar to what FF6 does on the world map to achieve the same effect), when I came to the conclusion that it was running rather slowly on my Athlon XP 2400, and that the scale filters would kill it completely, not even with anything important going on (like the entire rest of the battle system). Maybe this was completely bad programming on my part, I won't deny it, but I just think it is a shame that my idea really isn't feasable with the current speed of rotscale and scaleblit.
Posted on 2004-03-08 00:37:32 (last edited on 2004-03-08 00:38:08)
|
Omni
|
Wait...what exactly is drawing the speed down?
I've made a rotating/scaling sprite engine before and it worked just fine before I decided to trash it.
Also, what does "rotating on the x axis" mean? I really can't think of that right now, but maybe I'm suffering temporary retardation.
If you're talking about the scale layers I think you are, then certain images in certain rectangles on the screen should be drawn at different scales, right? Now, unless V3 is really unoptimized (I haven't tried scaling/rotating at all) this shouldn't be a problem.
A rotating ground plane. Does that mean you are simply blowing a RotScaled picture to the screen, or are you trying to do a Mode7 effect? I can't really get a clear picture of what you're having to do here, but simple rotation and scaling shouldn't bog the system down...
Posted on 2004-03-11 02:10:24
|
blues_zodiakos
|
It's very probable, the more I think about it and look back through my code, that the slow down was really my fault. Basically, I was trying to give the effect of a camara rotating around a fixed point, using rotscaled sprites to kind of "fake" the effect. There were two sprites being used, one that was the background of the picture (a picture of a rolling plains, for example) that would be wrapblitted +x or -x depending on what way the camera was moving. The second sprite was rotated, a section in the middle was grabbed from it, and the sprite was scaleblitted to the lower half of the screen to make it appear 'squashed'. This kind of had the effect I was looking for, except that there was no perceptual depth to it. I'm not really a good programmer yet, so it is very probable I just wasn't doing it right at all.
Does that make more sense?
Posted on 2004-03-11 05:39:50 (last edited on 2004-03-11 05:40:41)
|
Omni
|
Kinda. I can understand the background, but I can't quite envision the perspective you're creating. Wouldn't happen to be able to post a screenshot would you?
I'm not quite sure what Wrapblitting has to do with "the effect of a camera rotating around a fixed point."
Posted on 2004-03-11 12:52:25
|
rpgking
|
Those "mode7" effects are usually expensive to do in software. The reason the SNES could do it so quick was that it was a hardware feature... Then again, if they could emulate this effect on the PS1 in software for games like FF6, then I'm sure there is a way to do a fast mode7 effect. :P
Posted on 2004-03-11 14:58:37 (last edited on 2004-03-11 15:04:01)
|
blues_zodiakos
|
Wrapblitting the background in the opposite direction as the ground plane was rotating made it look like the camera was rotating. It's the same effect as in any other demo that does the same thing, even ones that use a polygon for the ground plane (like any 3d battle engine ever made).
Posted on 2004-03-11 18:57:59
|
Omni
|
I think I get what you're saying.
It's like the 2D scrolling background you see in a lot of 3D engines (for example, Mario 64). I can see what the code was trying to do now. Shouldn't be so slow to absorb processing power with just WrapBlits though.
Also, the reason why they were able to do Mode7 fake on the PSX so well in FFAnthology was because Sqaure probably mapped the bitmap to an actual polygon, which could then be rotated and scaled like a Mode7 surface.
On the other hand I hear the PSX Grandia's emulation of Mode7/whatever it was they used in the intro sequence on the Saturn was pretty darn sorry.
Posted on 2004-03-11 23:19:22
|
blues_zodiakos
|
Yep, you've got it. I think the thing that was slowing it down was the rotscales, though.
I've come to the conclusion that what I was trying to do is simply beyond my scope until there is an easy way to treat a sprite like a flat square polygon (like mode7). Using my fake-o tricks is just too CPU intensive, and produces far worse results.
Posted on 2004-03-12 06:06:35
|
Omni
|
Quick check, because I haven't looked.
Does Verge3 have the TMapPoly command? Or a DistortBlit command?
If so, you can use those to distort an image in the correct manner.
To do it, you will probably have to be able to rotate the corners of the sprite correctly, of course. It's somewhat advanced, but it isn't exactly knowledge that only a professional would know.
This will require trig. If you are new to trig stuff/didn't ever plan to use it, want to know what it does, and other neat things about rotation, scaling, and how to create a Mode7 effect (though it is a little advanced), go here:
Sin and Cos: Programmer's Pals
You may be particularly interested in the code to blit a sprite based on a rotation plane.
Posted on 2004-03-13 00:17:05 (last edited on 2004-03-13 00:19:29)
|
blues_zodiakos
|
Ooh, that may be exactly what I need! Thanks a million!
Posted on 2004-03-13 03:52:00
|
Displaying 1-15 of 15 total.
1
|
|
