Ummm, I think there''s another way of writing that, try:
movq MM0, QWORD PTR [esi]
Well, maybe some of the other Assembler guru''s should give you some more advice as well..
And what do you mean esi has wrapped around?
See ya,
Ben
P.S. Oh yah, Alt+F4 does wonders, have you guys ever tried closing your eyes and pressing Ctrl+Alt+Delete two or three times. Wow, it''s amazing!
How to do fast ASM blt? -no asm xp
BeanDog: I need to project to try to do anything else with it. You''re probably are using it in the wrong context.
Cyberben: Yeah, I tried it. The firework effects in the pong easter egg are really amazing!
Cyberben: Yeah, I tried it. The firework effects in the pong easter egg are really amazing!
Author
Cyberben: I mean, with unsigned values, if you subtract past 0, it wraps around to the highest value. Like this:
unsigned char x = 5;
x--; //x=4
x--; //x=3
x--; //x=2
x--; //x=1
x--; //x=0
x--; //x=255
You see?
blue-lightning: I use the Pcopy routine you see, and call it with this line of code:
Pcopy(TerrainLayer, Back, 800, 600, false);
(previously, the last bool value was whether or not to use color keying)
Hope this helps clear it up,
~BenDilts( void );
unsigned char x = 5;
x--; //x=4
x--; //x=3
x--; //x=2
x--; //x=1
x--; //x=0
x--; //x=255
You see?
blue-lightning: I use the Pcopy routine you see, and call it with this line of code:
Pcopy(TerrainLayer, Back, 800, 600, false);
(previously, the last bool value was whether or not to use color keying)
Hope this helps clear it up,
~BenDilts( void );
BeanDog: Could you send me all of the source files so I can run it through my debugger? I don''t want to make a shell project for it.
For a good time hit Alt-F4! Go ahead try it, all the cool people are doing it.
For a good time hit Alt-F4! Go ahead try it, all the cool people are doing it.
How do you check your DD caps for sys->vid hardware blitting? You
think you would at least check first before even assuming your user''s
card doesn''t support it.
think you would at least check first before even assuming your user''s
card doesn''t support it.
5.) I''ve already been told about not using push and pop, because alledgeadly (sp?) these instructions are quite slow on certain computers and are fast on others. When you count it up with intel''s timing info. To re-calc the width of the blit each loop iteration would take the "same" number of cpu cycles on a intel system however it should be much faster on other systems.
AHHH! Don''t make that mistake! Intel''s timing info is measuring how long the instruction would take AT A MINIMUM. Things like pre-fetch instructions (loading the instructions themselves), VGA Refresh (about 1 in every 7 cycles I think), pipelined CPUs, and lots of other cycle-stealers will slow down your instructions. However, every computer is different. In fact, probably every time you go through the procedure you made, it will take a different amount of time to process.
Moral? Don''t trust Intel! Time the procedure as best you can on as many computers as you can, and don''t just time it once. Since it may take different amount of time to process, time the procedure a million times or so and average the results. The reason why push/pop may take different amounts of time on different systems is most likely because they''re different systems. Once the instruction is pre-fetched, the VGA Refresh is done, and all overhead is cleared, THEN the instruction will take exactly as long as Intel said...maybe. So don''t trust Intel. They''re right - until you have to do CPU cycle counting yourself and realize that they''re wrong!
OK, ok, I''ve controlled myself, I''m better now. Just don''t trust CPU cycle counts, ok?
-Ender Wiggin
AHHH! Don''t make that mistake! Intel''s timing info is measuring how long the instruction would take AT A MINIMUM. Things like pre-fetch instructions (loading the instructions themselves), VGA Refresh (about 1 in every 7 cycles I think), pipelined CPUs, and lots of other cycle-stealers will slow down your instructions. However, every computer is different. In fact, probably every time you go through the procedure you made, it will take a different amount of time to process.
Moral? Don''t trust Intel! Time the procedure as best you can on as many computers as you can, and don''t just time it once. Since it may take different amount of time to process, time the procedure a million times or so and average the results. The reason why push/pop may take different amounts of time on different systems is most likely because they''re different systems. Once the instruction is pre-fetched, the VGA Refresh is done, and all overhead is cleared, THEN the instruction will take exactly as long as Intel said...maybe. So don''t trust Intel. They''re right - until you have to do CPU cycle counting yourself and realize that they''re wrong!
OK, ok, I''ve controlled myself, I''m better now. Just don''t trust CPU cycle counts, ok?
-Ender Wiggin
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
