2010/1/14 Jay Tennant <[email protected]>:
>> From: Ralph Versteegen <[email protected]>
>> Sent: Tuesday, January 12, 2010 8:33 AM
>>
>> 2010/1/6  <[email protected]>:
>> > jay
>> > 2010-01-05 09:04:08 -0800 (Tue, 05 Jan 2010)
>> > 461
>> > gfx_sdl backend, update. Working on rewriting the sdl backend--also means 
>> > removing Windows dependencies--so gfx_sdl can be loaded just like 
>> > gfx_directx, and with cleaner interfacing. Also adding gfx_common that 
>> > contains source that will be common to all backends implemented as dll's. 
>> > Still need to remove duplicate source in gfx_directx, gfx_sdl, and 
>> > gfx_common. Also, need to build platform independence into all gfx_common 
>> > files (specifically, "_tstring.h").
>> > ---
>> > A   wip/gfx_common/
>> > A   wip/gfx_common/_tstring.cpp
>> > A   wip/gfx_common/_tstring.h
>> > A   wip/gfx_common/fb_scancodes.h
>> > A   wip/gfx_common/gfx_msg.h
>> > A   wip/gfx_common/gfx_palette.h
>> > A   wip/gfx_sdl/
>> > A   wip/gfx_sdl/source/
>> > A   wip/gfx_sdl/source/Graphics.h
>> > A   wip/gfx_sdl/source/Input.h
>> > A   wip/gfx_sdl/source/Window.h
>> > A   wip/gfx_sdl/source/_tstring.cpp
>> > A   wip/gfx_sdl/source/_tstring.h
>> > A   wip/gfx_sdl/source/fb_scancodes.h
>> > A   wip/gfx_sdl/source/gfx_msg.h
>> > A   wip/gfx_sdl/source/gfx_palette.h
>> > A   wip/gfx_sdl/source/gfx_sdl.cpp
>> > A   wip/gfx_sdl/source/gfx_sdl.h
>>
>> This is rather absurdly delayed but:
>>
>> What are the goals of this C++ rewrite? I guess you just wanted to
>> push on with the new interface rather than waiting for me to rewrite
>> all the backends :)
>
> Essentially, yes. I didn't want to put all the coding burden on you, and I 
> wanted to learn the sdl api.

OK, but no need to make it unnecessarily complex. I notice some stubs
functions for aspect ratio preservation. Do you actually intend to
implement this?

>> Also, I still don't see significant benefit to run-time linking
>> backends, but that's OK, it should not be hard to statically link it.
>
> Uniform interface for the backends/engine, smaller app size, the backend 
> would be the only os-specific object--therefore, only one engine compile and 
> a user-selected backend, called ie: "game.exe -gfx gfx_directx.dll" or 
> "game.exe -gfx gfx_sdl.dll", etc. Perhaps if "game.exe" is called, it 
> searches for a "default" backend, such as gfx_sdl.dll.
>
> If there was only 1 backend, there'd not be much point to this. Because there 
> are 4 backends, however, the justification is there. As an example you can 
> look at different emulators, such as ePSXe, that require you to acquire a few 
> backends to fully run. We don't need to make the ohr engine that complex, but 
> separating the backend from the engine is a good idea. That also means that 
> if a backend works perfectly, we don't have to re-release it. Or if the 
> backend is the only element needing adjustment, we don't have to re-release 
> the entire engine.

While I still don't see the benefits as too significant, I can't
really help but agree that it would be nice. Of course, gfx_fb and
gfx_alleg can stay how they are.

I think the new interface still needs more changes but will talk about
that some other time.
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org

Reply via email to