1. ememcopy
Hawke,
Yeah, I went back over my code, but here's what I found:
given:
sequence virtualmonitor
virtualmonitor = {{},{}}
wt = 1023
ht = 767
virtualmonitor[1] = {wt, ht}
virtualmonitor[2] = allocate(wt*ht)
display_svga_image(1, virtualmonitor[2], {wt,ht}, {0,0})
The image I store at virtualmonitor[2] is set to the screen (sans the
last column and row).
If I set wt = 1024, and ht = 768, I get causeway errors (whatever those
are).
Don't fret too much, the code works w/ 1023x767, and its' not like I do
anything particularly serious.
On to other things:
My mode 259 returns that it is functioning properly from video_config,
and it does display pixels, however, it appears that the screen is
incorrectly laid out algorithmically. Succeding rows of pixels are not
offset in the video memory correctly, such that images are radically
skewed. This, using libraries which came with euphoria. Even text and
the mouse are skewed. Any thoughts? (other than don't use that mode)
snortboy
2. Re: ememcopy
Noah Smith wrote:
> sequence virtualmonitor
> virtualmonitor = {{},{}}
> wt = 1023 ht = 767
> virtualmonitor[1] = {wt, ht}
> virtualmonitor[2] = allocate(wt*ht)
> display_svga_image(1, virtualmonitor[2], {wt,ht}, {0,0})
Try this instead:
------begin code (sorry, untested)
constant Width =1024, Height=768
constant MaxX =1023, MaxY =767
constant Origin={0,0}
object VirtScr
VirtScr =allocate(Width*Height)
--option 1
--(this *should* be the correct one, mapping 0..1023,0..767)
--(but it depends on the coder of disp_svga_img, a matter of style)
display_svga_image(1, VirtScr, {MaxX,MaxY}, Origin)
--option 2
--(but it could be this one... mapping 1024 x 768 'positions')
display_svga_image(1, VirtScr, {Width,Height}, Origin)
------end code
Now, either option1 or option2 should in theory work,
and work correctly.
The documentation for display_svga_image is a little
vague as to that 3rd argument, and reading the function
didn't help much either.
Please humor an old fart and try them both.
The biggest difference between your
version and mine, is the allocate line.
From the descriptions of your errors/screwed
screens, it sounds like your indexing/indices
are defn'ly off by 1, and the result of that
is that in your allocate line you aren't reserving
enough "locations" to store pixel data in.
This would also account for the skewed screens, as
you will get a wrap-around effect.
Hopefully, my analysis and solution are actually correct.
Hopefully, my analysis and solution are actually helpful.
:)
--Hawke'
3. ememcopy
Hi Everybody!
Last night I finally got round to inspecting Michael Bolin's
extended mem_copy() routine: such a good idea! I shoved it
into my vgraph library, and to my amazement, frame rates of
some of my demos actually dropped! If you do not believe me,
try the little test below. You will need my vgraph.e and
Michael's emecopy.e as well.
And moral of the story? Somewhat contrary to Michael's own
advice, use it for simple copying (kind=1) only if you don't
mind a marginal performance degradation, but certainly use
it with kind=2 or 3, if you want your sprites to fly! Jiri
-- snip ----------------------------------------------------
-- emctest.ex: testing Michael Bolin's extended mem copy routines
-- j.babor at gns.cri.nz
include get.e -- wait_key()
include image.e
include ememcopy.e
include vgraph.e
constant
tile={{0,0,0,8,8,7,7,15,15},
{0,0,8,8,7,7,15,15,0},
{0,8,8,7,7,15,15,0,0},
{8,8,7,7,15,15,0,0,0},
{8,7,7,15,15,0,0,0,8},
{7,7,15,15,0,0,0,8,8},
{7,15,15,0,0,0,8,8,7},
{15,15,0,0,0,8,8,7,7},
{15,0,0,0,8,8,7,7,15}}
object junk
sequence s
atom dt,t
-- main ------------------------------------------------------------------------
junk=graphics_mode(19)
tick_rate(100)
junk=set_up_emc()
-- time tests: 1000 iterations
v_box(tile,1,{0,0},{159,99})
t=time()
for i=1 to 1000 do
v_copy_region(#A0000,320,{160,100},#A0000,320,{{0,0},{159,99}})
end for
dt=time()-t
position(15,1)
printf(1,"v_copy_region:%5.2f\n",dt)
t=time()
for i=1 to 1000 do
se_mem_copy (1, #A0000, #A0000+32160, 160, 100, 320-160, 320-160)
end for
dt=time()-t
printf(1,"se_mem_copy: %5.2f\n\n",dt)
-- generate a simple hollow sprite shape & save it
ellipse(14,1,{210,10},{249,49})
ellipse(0,1,{220,20},{239,39})
s=save_image({210,10},{249,49})
t=time()
for i=1 to 1000 do
v_merge_image({10,10},s)
end for
dt=time()-t
printf(1,"merge_image: %5.2f\n",dt)
t=time()
for i=1 to 1000 do
se_mem_copy (2,#A0000+10*320+210,#A0000+10*320+60,40,40,320-40,320-40)
end for
dt=time()-t
printf(1,"se_mem_copy: %5.2f\n",dt)
t=time()
for i=1 to 1000 do
se_mem_copy (3,#A0000+10*320+210,#A0000+10*320+110,40,40,320-40,320-40)
end for
dt=time()-t
printf(1,"se_mem_copy: %5.2f\n",dt)
junk=wait_key()
junk=graphics_mode(-1)
4. Re: ememcopy
I also found that ememcopy is very useful for kind 2 and 3 operations, but
when I got to updating the whole screen, a ememcopy kind 1 was to slow, so
I had to use a normal memcopy. This was to keep up with the refresh rate of
my monitor. And, thanx to Pete Eberlein, your solution was a good one, and
now my platform library is getting along. I'll post it to the official
Euphoria Site when it is finished. Of course, I might stumble into more
problems.
Einar Mogen
5. Re: ememcopy
- Posted by Michael Bolin <michaeltom at GEOCITIES.COM>
Sep 06, 1997
-
Last edited Sep 07, 1997
> Last night I finally got round to inspecting Michael Bolin's
> extended mem_copy() routine: such a good idea! I shoved it
> into my vgraph library, and to my amazement, frame rates of
> some of my demos actually dropped! If you do not believe me,
> try the little test below. You will need my vgraph.e and
> Michael's emecopy.e as well.
>
> And moral of the story? Somewhat contrary to Michael's own
> advice, use it for simple copying (kind=1) only if you don't
> mind a marginal performance degradation, but certainly use
> it with kind=2 or 3, if you want your sprites to fly! Jiri
When I tried it, my routine was still a couple of percent faster, but
maybe that's just on this machine.
But I know what the reason for it is:
Both the built in mem_copy() and my routine use a copying method that
is extremely close to the fastest possible. The built-in command has
the advantage of having the Euphoria interpreter pass the values to
it, while my routine must use poke() for each argument before calling
the ML routine. I have actually written some ML routines for a
Euphoria program before, and found out that the pokes necessary before
calling it were taking longer to execute than the routine itself!
If only Robert would add some method of passing values to call()...
Regards,
Michael Bolin
6. Re: ememcopy
Michael Bolin writes:
> I have actually written some ML routines for a
> Euphoria program before, and found out that the pokes necessary before
> calling it were taking longer to execute than the routine itself!
> If only Robert would add some method of passing values to call()...
In the next release for DOS and for Windows, there will be a fast
poke4() routine that will efficiently poke an atom as 4 bytes
into memory. That way you won't have to call int_to_bytes()
before poking.
By the way, I'm still working hard on the WIN32
version. Expect somewhat more functionality than
I promised a few months ago, but I still need another
month or two before I can release an alpha.
There are improvements in store for the DOS version
as well.
Regards,
Rob Craig
Rapid Deployment Software
7. Re: ememcopy
At 04:55 AM 9/7/97 UT, you wrote:
>
>By the way, I'm still working hard on the WIN32
>version. Expect somewhat more functionality than
>I promised a few months ago, but I still need another
>month or two before I can release an alpha.
Well, if you could... I need that by tomorrow. :)
>There are improvements in store for the DOS version
>as well.
Is there a PowerMac version being made? What about a UNIX version?
Thanks!
ck
8. Re: ememcopy
C.K. Lester asks:
> Is there a PowerMac version being made? What about a UNIX version?
Euphoria is not hard to port, being 99% C, 1% assembly.
I hope to do Euphoria for Linux and maybe the PowerMac,
but at the moment I'm concentrating on WIN32 and DOS.
Regards,
Rob Craig
Rapid Deployment Software
9. Re: ememcopy
>
>Euphoria is not hard to port, being 99% C, 1% assembly.
>I hope to do Euphoria for Linux and maybe the PowerMac,
>but at the moment I'm concentrating on WIN32 and DOS.
Cool! Um... how about we start a "Clone R. Craig" fund... anybody?
