![]() |
|
DirectX VRAM-VRAM accelerated stretch blit |
Evert
Member #794
November 2000
![]() |
Quote: Evert, my entire post is one statement, i wasn't expecting to have individually sentences picked apart, reading the post backwards takes it out of context. I thought I'd structure my reply in such a way that I could individually comment on the things I have questions about. I also thought that I'd just put the quick question in front, before the one where I would put a bit more discussion or clarification to what I was saying. But if you prefer it the other way around (and you might bother answering the question this time): Allegro uses self-modifying code to stretch sprites on Intel machines (more accurately put, it assembles a piece of code in memory to do the stretching and then calls it). I can imagine that that can still be an efficient way of doing it on modern machines (even if the code generated is i386 oriented). And what do you mean be `luck making a stretch_blit in C'? Allegro already has one; have you looked at that? By the way, as this has nothing to do with the original topic (VRAM->VRAM accelerated stretch blits), I'd prefer the discussion be moved to its own thread to make it easier to track. |
A J
Member #3,025
December 2002
![]() |
Quote: what do you mean be `luck making a stretch_blit in C'? I mean, has anyone made a stretch_blit in C, not asm, that can compile on all the supported compilers, and is as fast or faster than the current asm stretch_blit code ? Quote: Allegro already has one; have you looked at that?
It has? where? Getting a straight answer seems to be really difficult, so all i can do is ask lots of questions; and pick apart a few answers to try to establish what is going on, and at the moment, it seems that there is consensus about droping the asm code ASAP, in favour of C equivalents. I can't establish the current state of that work, for direct and specific questions like "As for the asm code in allegro, which routines need re-writing?", the answer i got was "all of them". As i have already written a fast SSE2 blit, and we all seem to be in agreement about memcpy() being a suffecient blit replacement; i thought i might try asking about the status of stretch_blit and wether anyone had written a C equivalant of it. Quote: and you might bother answering the question this time
Quote: .. obviously someone has had some luck... i'll obviously answer when i could be bothered ___________________________ |
Fiddler
Member #5,385
January 2005
|
A J, Evert is trying to say that Allegro already has a C version of stretch_blit, which is used in all platforms except for the x86 CPUs. You can use that as a base trying to develop a possibly faster version. The Open Toolkit: a game development library for .Net/Mono. |
Evert
Member #794
November 2000
![]() |
Quote: It has? where? allegro/src/c/cstretch.c Quote: Im confused, as when i asked "As for the asm code in allegro, which routines need re-writing?" i didn't get a specific answer, but i did get a hint "Only 32 bit Intel ports use ASM code"
Well, what are you asking? What routines need to be rewritten in C because there's only an ASM version of the code? or If I want to make more efficient ASM code routines, which routines should I rewrite? Quote: it seems that there is consensus about droping the asm code ASAP, in favour of C equivalents. Yes. The main reason being, if and when things are changed in the API, we don't want to simultaneously be developing an ASM and a C version of the code. We need the C version anyway, so let's stick with that, at least for now. Quote: As i have already written a fast SSE2 blit, Did you submit a patch for that? Quote: i thought i might try asking about the status of stretch_blit and wether anyone had written a C equivalant of it.
Yes, of course someone has - or Allegro would not work on non-i386 machines. Quote:
Quote: Quote: i'll obviously answer when i could be bothered Well, I assumed you were aware that Allegro works on non-Intel machines (G4/G5 Mac's, say), so I assumed you were aware of the Allegro C-only port. If you weren't, fair enough. If you were, I still don't understand your question. |
|
|