On 07.04.2011 0:11, Nick Sabalausky wrote:
> "Adam D. Ruppe"<destructionator@gmail.com>  wrote in message
> news:ini1jr$2lj3$1@digitalmars.com...
>> Nick Sabalausky wrote:
>>> Of course, if you see any fundamental
>>> problems with this, feel free to let me know :)
>> I'm pretty sure your plan would work and would provide a boost,
>> but I'm not sure if it's worth the extra time.
>>
>> I think the best thing to do will be to partially implement it,
>> write a little program with both methods and run some speed tests.
>> See if it's still easy to use and how big the difference really is.
>>
>
> Yea, sounds like a good plan. Although, my design is heavily dependent on
> inlining working, so that may be a problem until DMD issue #5708 gets fixed:
> http://d.puremagic.com/issues/show_bug.cgi?id=5708
>
> There another similar -inline related bug in there too, but I don't remember
> offhand what it is.
>
>>> And even then, things like line drawing, fills and image
>>> blitting are still better off skipping the
>>> individual-pixel-access routines
>> Aye, even my homegrown DOS would always write them separately.
>> Horrible waste of instructions doing another y<<  8 + y<<  6 when
>> a simple "inc ax" would suffice!
>>
> Yup, exactly. Which reminds me, I've always wanted to actually check to see
> if modern compilers (or at least DMD) would be smart enough to optimize
> something like:
>
> for(i in 128...256)
>      arr[i] = ...;
>
> Into something like:
>
> auto ptr = arr.ptr + 128;
> auto ptrEnd = arr.ptr + 256;
> for(; ptr<  ptrEnd; ptr++)
>      *ptr = ...;
>
> My guess is no (and I'm fairly certain it was "no" back in my DOS days: that
> was the sort of manual optimization I remember doing all the time), but with
> all the improvements that optimizers keep making, I'm not really sure
> anymore.
>
> Of course, even if the compiler can optimize that, I still doubt it would be
> able to automatically do an equivalent optimization to effectively create,
> for example, Bresenham's algorithm (ie, straight diagonal lines between two
> arbitrary points).
>
>>> But anyway, I don't know exactly how you were going about it, but
>>> the way to do this in OpenGL or DirectX would be to do all your
>>> drawing to a texture buffer
>> I at first just used a SetPixel function in opengl, but when it
>> was unacceptable, I simply abandoned the idea of drawing pixels
>> to the screen. Instead, I started focusing on polygons and textures -
>> a rectangle with a bitmap attached as a texture makes an excellent
>> sprite that draws very very quickly, even if rotated or misshapen.
>>
>> Once I realized that works so well, pixels weren't important
>> anymore so I just stopped using the old functions entirely. They're
>> still in the code, still godawfully slow, but I don't care enough
>> to change it.
>>
> Yea. I see. I wonder if OpenGL's SetPixel was inlined. If not, I bet we
> could do better (as long as we had direct access to the texture's buffer).
>

Mmm, am I the only one wondering where did you guys get SetPixel in OpenGL ?  It's must have been GDI.
At any rate OpenGL and DirectX is all about sending commands and data back and forth between  CPU and videocard (well, there is driver involved, doing some translation into specific chip's commands and such).
So no, SetPixel couldn't exactly get inlined just because you can't access video ram without jumping through some hoops:  OS -> HAL-> driver ------->PCI-E or AGP -> ... -> video RAM.  OpenGL and DirectX subsytems bypass some of these additional hoops, but still you have to send the data down this route. That's why it's usually used for massive asynchronous transfers.
E.g. every time you need GetPixel you send "read pixels command" and wait utill all the data already streamed in is processed and stored in the video RAM, then it reads framebuffer and sends you results (effectively stalling all it's processors).
So for "straight" setpixel/putpixel drawing, software render + blit to screen is the way
(but I  doubt you need only pixels, and going futher inevitably shows why software render sucks).

-- 
Dmitry Olshansky

Am 06.04.2011 22:50, schrieb David Nadlinger:
> On 4/6/11 10:41 PM, Nick Sabalausky wrote:
>>> I don't think having fixed-size image will be a useful optimization,
>>> except perhaps if you manipulate a lot of tiny images of the same size.
>>>
>>
>> Manipulating images in software involves accessing a *lot* of pixels,
>> so you
>> have a very big "inner loop" situation. If the width isn't
>> statically-known,
>> then:[…]
>
> If you want to write something generic that actually performs well, the
> Adobe/Boost »Generic Image Library« might be an interesting example:
> www.boost.org/doc/libs/release/libs/gil/doc/index.html
>
> David


Thank's for sharing. Seems to be a cool project.
I will have a look at it.

°Matthias

Dmitry Olshansky wrote:
> Mmm, am I the only one wondering where did you guys get SetPixel in OpenGL ?  It's must have been GDI.

Oops, looks like you're right. SetPixel is GDI, and it's pretty slow too. Looking at my code, I used glBegin(GL_POINTS); glVertex2f [...] glEnd() as the opengl putpixel. Looks like in an earlier revision, I also used glDrawPixels at some point, but I didn't keep it for some reason. Don't remember why (or even what it does.)

But yeah, it's been a while and my brain jumbled it all together... sorry about that.

"Dmitry Olshansky" <dmitry.olsh@gmail.com> wrote in message news:inik5u$n13$1@digitalmars.com...
>
> Mmm, am I the only one wondering where did you guys get SetPixel in OpenGL
> ?  It's must have been GDI.
> At any rate OpenGL and DirectX is all about sending commands and data back
> and forth between  CPU and videocard (well, there is driver involved,
> doing some translation into specific chip's commands and such).
> So no, SetPixel couldn't exactly get inlined just because you can't access
> video ram without jumping through some hoops:  OS -> HAL->
> driver ------->PCI-E or AGP -> ... -> video RAM.  OpenGL and DirectX
> subsytems bypass some of these additional hoops, but still you have to
> send the data down this route. That's why it's usually used for massive
> asynchronous transfers.
> E.g. every time you need GetPixel you send "read pixels command" and wait
> utill all the data already streamed in is processed and stored in the
> video RAM, then it reads framebuffer and sends you results (effectively
> stalling all it's processors).
> So for "straight" setpixel/putpixel drawing, software render + blit to
> screen is the way
> (but I  doubt you need only pixels, and going futher inevitably shows why
> software render sucks).
>

What I was thinking of was using some set/get pixel stuff to draw to system-ram and then use OpenGL/DirectX to transfer it to video-ram when done (I have no idea which way Adam was doing it).

And yea, you're right that software rendering sucks performance-wise. But the main orginal point was t have a way to just toy around with image drawing in an easy classic DOS-style. From there, my thoughts were "ok, how to make this approach as close to being efficient as it can realistically get?"

I'm snipping a bit since we're on the same page.

Nick Sabalausky wrote:
> Yea. I see. I wonder if OpenGL's SetPixel was inlined.

Note my mistake: SetPixel is GDI. I got it mixed up in my brain.

>  Did you say this would ideally be something for Phobos?

Yes, I hope so. It'll be nice for D if newbies can dive right into this stuff out of the box.

> And along the NES/SNES lines, I've always been a huge sucker for DOS VGA/EGA gaming.

Another great thing was all you could do with the text mode, like Walter's Empire DOS version.

That oem character set with the 80x25 cell display, 16 color palette.. and, of course, the blink bit could go incredibly far in making a nice little game board.

> You'd probably need DOSBox for all of them these days.

DOS programs are one reason why I was so reluctant to get into the
64 bit bandwagon. I eventually caved in a few months ago when
my old motherboard gave up the magic smoke, but I really didn't
want to lose native 16 bit ability!

DOSBox does the job, but I've always found it hard to use compared to the "real" thing.

"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:inimg1$t0m$1@digitalmars.com...
> Nick Sabalausky wrote:
>> And along the NES/SNES lines, I've always been a huge sucker for DOS VGA/EGA gaming.
>
> Another great thing was all you could do with the text mode, like Walter's Empire DOS version.
>

I admit I've never actually played any version of Empire. But then I've never really been particularly into resource-management strategies (I *think* that's what Empire is...something similar to Civilazation, right?)


> That oem character set with the 80x25 cell display, 16 color palette.. and, of course, the blink bit could go incredibly far in making a nice little game board.
>

Yea. Kroz and ZZT were great. And I made a few little text-mode games in QBASIC a lifetime ago (And posted them on AOL, way back at AOL v1.x :) Pre-web, heh). Still have those QBASIC games around here somewhere. The characters for the extended-ASCII range and control codes were really useful (the walls, the two "face" characters, etc). I totally forgot about the blink bit!


>> You'd probably need DOSBox for all of them these days.
>
> DOS programs are one reason why I was so reluctant to get into the
> 64 bit bandwagon. I eventually caved in a few months ago when
> my old motherboard gave up the magic smoke, but I really didn't
> want to lose native 16 bit ability!
>
> DOSBox does the job, but I've always found it hard to use compared to the "real" thing.

I had no idea the 64-bit chips couldn't do 16-bit!

I'm actually not real concerned about that though. I've found that a *lot* of the old DOS stuff I like is entirely broken on my modern(-ish) 32-bit XP system (and a lot of it never played well with Windows in the first place), so I usually have to use either DOXBox or my old 486 anyway. Not that DOSBox is perfect yet, unfortunately, but it seems to actually have much better compatibility than trying to run things "natively".

"David Nadlinger" <see@klickverbot.at> wrote in message news:inijsn$m9r$1@digitalmars.com...
> On 4/6/11 10:41 PM, Nick Sabalausky wrote:
>>> I don't think having fixed-size image will be a useful optimization, except perhaps if you manipulate a lot of tiny images of the same size.
>>>
>>
>> Manipulating images in software involves accessing a *lot* of pixels, so
>> you
>> have a very big "inner loop" situation. If the width isn't
>> statically-known,
>> then:[.]
>
> If you want to write something generic that actually performs well, the Adobe/Boost »Generic Image Library« might be an interesting example: www.boost.org/doc/libs/release/libs/gil/doc/index.html
>

Just took a brief glance. Does seem potentially interesting. Appears to essentially be a C++ std.range/std.algorithm for images. I can imagine a similar approach might be fruitful for us.

On 07.04.2011 1:29, Adam D. Ruppe wrote:
> Dmitry Olshansky wrote:
>> Mmm, am I the only one wondering where did you guys get SetPixel in
>> OpenGL ?  It's must have been GDI.
> Oops, looks like you're right. SetPixel is GDI, and it's pretty
> slow too. Looking at my code, I used glBegin(GL_POINTS); glVertex2f
> [...] glEnd() as the opengl putpixel. Looks like in an earlier
> revision, I also used glDrawPixels at some point, but I didn't keep
> it for some reason. Don't remember why (or even what it does.)
>
> But yeah, it's been a while and my brain jumbled it all together...
> sorry about that.
Ah,  I see. No problem, and, yes, fro me OpenGL never got drawing single pixels this way,
 and still not fast enough even when packed in single array. DrawPixels is for drawing block of pixel data (2D images), technically it can draw 1x1 image.
As for the topic of messing old school DOS-like messing with image, I think there was some peculiar MMX-based
code for that buried somewhere in SDL, may be it can be revived in SSE2 world :)
Long time ago I also sought out simplistic GUI system with direct framebuffer, I ended up with design
Windowing System <-> GL <- blit -> software renderer should be easily portable as far as the wrapper around windowing system is minimalistic (e.g. map repaint, keys and mouse events).

-- 
Dmitry Olshansky

Nick Sabalausky wrote:
> I admit I've never actually played any version of Empire. But then I've never really been particularly into resource-management strategies (I *think* that's what Empire is...something similar to Civilazation, right?)

I've never played Civilization! But, I wouldn't call it resource
management really. Every turn, you can make more units (more
or less depending on how many cities you've captured), and while
that's an important part of the game, I'd say more of it is
positioning your guys and advancing without leaving your own cities
open to be conquered.

Resource management makes me think of something like Warcraft where controlling the gold mines is more important than army positioning. Holding cities is vital to victory in Empire, but positioning your army is at least as important too.

> I had no idea the 64-bit chips couldn't do 16-bit!

Then can, but not when they are in 64 bit mode.

In 32 bit mode, it's the same as the old chips. You can run 32 bit code and 16 bit code side by side, but no 64 bit.

In 64 bit mode, you can now run 64 and 32 bit code together, but no 16 bit.

The mode it runs in depends on your operating system. Put a 32 bit OS on the 64 bit chip and everything works the same as the old processors. But, if you want to actually use the new capabilities, you've gotta go with a 64 bit OS, which means losing native 16 bit (at least until you reboot into 32 or 16 bit OS)

Am 07.04.2011 00:33, schrieb Adam D. Ruppe:
> Nick Sabalausky wrote:
>> I admit I've never actually played any version of Empire. But then I've never really been particularly into resource-management strategies (I *think* that's what Empire is...something similar to Civilazation, right?)
> 
> I've never played Civilization! But, I wouldn't call it resource
> management really. Every turn, you can make more units (more
> or less depending on how many cities you've captured), and while
> that's an important part of the game, I'd say more of it is
> positioning your guys and advancing without leaving your own cities
> open to be conquered.
> 
> Resource management makes me think of something like Warcraft where controlling the gold mines is more important than army positioning. Holding cities is vital to victory in Empire, but positioning your army is at least as important too.
> 
>> I had no idea the 64-bit chips couldn't do 16-bit!
> 
> Then can, but not when they are in 64 bit mode.
> 
> In 32 bit mode, it's the same as the old chips. You can run 32 bit code and 16 bit code side by side, but no 64 bit.
> 
> In 64 bit mode, you can now run 64 and 32 bit code together, but no 16 bit.
> 
> The mode it runs in depends on your operating system. Put a 32 bit OS on the 64 bit chip and everything works the same as the old processors. But, if you want to actually use the new capabilities, you've gotta go with a 64 bit OS, which means losing native 16 bit (at least until you reboot into 32 or 16 bit OS)

You can probably just run a 32bit VM with DOS (or Win9x or something) in
it (via VirtualBox or similar).
Maybe in some cases this runs better than DosBox (Or at least as good as
a native 32bit Windows).

Cheers,
- Daniel