On Saturday 04 August 2012 23:33:26 wahono sri wrote:
> How to implement ttextstream.linecount?
> I got SIGSEGV : fpc_ansi_str_decr_ref
>
Please try again with git master d23dbd56477d7d93068ef4555ae20f42a0e624d1.
Martin
-
On 4 August 2012 19:58, wahono sri wrote:
> How about you Graeme? AggPas or ZenGL as new options?
I don't know anything about ZenGL, so I can't comment. Today was the
first time I heard about ZenGL. :)
--
Regards,
- Graeme -
___
fpGUI - a cross
some demos of ZenGL are smashing
===
Hmm..."demo08" causes 100% GPU (not CPU!) load on my ATI 6850 (me
didn't even see it in heavy games), and i's a good feature that the
library is capable of utilizing all power of non-CPU hardware.
---
How to implement ttextstream.linecount?
I got SIGSEGV : fpc_ansi_str_decr_ref
afile:= ttextstream.create(wfilerestore.value);
str2:= '';
int1:= afile.linecount; =>
Thanks
--
Live Security Virtual Conference
Exc
AggPas or ZenGL as new options?
AFAIK, AggPas is designed for image processing solely. ZenGL - all GUI
related issues.
PS:
1) some demos of ZenGL are smashing, for instance - having 5600fps (!!!)
2) being "russian" is good in that sense that all non-latin issues
will be polished & we'll d
> Then Martin won't have time to sleep :) There're must be 2+ core
> developers to absorb such increase.
I think with ZenGL more easyly than linking from C/C++ library. And as
Martin say, msefreetype.pas and msefontcache.pas is ready, so just
need compromising with ZenGL to add some functional nee
- Spread community to increase MSEgui popularity
=
Then Martin won't have time to sleep :) There're must be 2+ core
developers to absorb such increase.
Official 64-bit support is needed
=
Yes, some people even tried to switch to FPC from Delphi exactly
because of X86_64 - b
> MSEgui as some other obstacles too. Official 64-bit support is needed
> (windows & linux). Mac support must be added too.
>
> --
> Regards,
> - Graeme -
And with ZenGL I think all platform 32&64 bit will be supported
(http://zengl.org/wiki/doku.php?id=compilation:basics).
How about you Graeme?
On 4 August 2012 19:47, wahono sri wrote:
> MSEide grow and can be used as RAD for game development, and
> certainly cross platform.
MSEgui as some other obstacles too. Official 64-bit support is needed
(windows & linux). Mac support must be added too.
--
Regards,
- Graeme -
Other advantages if MSEgui combine with ZenGL are (symbiotic mutualism):
- Spread community to increase MSEgui popularity
- ZenGL doesnt have own GUI, and games need GUI for configuration,
interaction with player, etc. And games developers that use ZenGL can
use MSEgui as their games GUI. Strategy
> But some modifications should be done are use msefreetype.pas to
> combine with ZenGL. And msefontcache.pas is good for combining.
>
AFAIK, SDL, SDL_ttf, SFML use freetype to text drawing and I think the
performance is good with SFML (with OpenGL), and certainly good for
SDL (but version 2.0 with
On 5 August 2012 00:47, Ivanko B wrote:
> SDL or SFML
> =
> Maybe Martin more needs to know from their code how to achieve better
> optimization for the native MSEgui OpenGL backend :)
If we want to use OpenGL backend, I think ZenGL is considerable
(http://zengl.org/features.html), withou
SDL or SFML
=
Maybe Martin more needs to know from their code how to achieve better
optimization for the native MSEgui OpenGL backend :)
--
Live Security Virtual Conference
Exclusive live event will cover all the w
All SDL stuff (inc subprojects) can be found at :
http://www.libsdl.org/projects/
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how
Most optimizations, tricks etc may be fount in :
http://www.arcsynthesis.org/gltut/
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and ho
2D acceleration: SDL can use OpenGL or Direct3D behind the scenes with
the 2D interfaces, so we can get acceleration on modern systems where
X11 or DirectDraw just aren't the fast paths anymore.
Expectable :) If the SFML team publishes (really) fake tests for
Me have two videocard on my home machine - the main (for primary
display) is ATI & the secondary (for game's PhisyX ) is NVidia.
Possibly the test program is buggy for running on this setup :)
--
Live Security Virtual Co
On 4 August 2012 23:13, Ivanko B wrote:
> BTW, the test doesn't start on Win7 x86_64 at all.
I use Win7 64 bit and it run. :)
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's secur
BTW, the test doesn't start on Win7 x86_64 at all.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discus
>Hmm...these horrible timings were with M$ drivers (possible s/w
> emulated OpenGL). With vedor drivers me have:
Ha ha ha, it's make us confusing. What's MS drivers did you use to
enable OpenGL 1.3? It's from NVidia or from MS?
=
But looking in code of the text, there're no tr
I've experienced about this problem in before 2000, Acosys which built
from VB6 is compared with competitor that use DOS programming, they
claim their app faster than my app, but after upgrade to new PC, old
app built with DOS programming run very slow than app built from
modern programming and loo
And bad news is SDL will follow SFML to increase speed in SDL 2.0 with
full hardware acceleration :
2. Special features in SDL 2.0 (http://wiki.libsdl.org/moin.cgi/Introduction)
Full 3D hardware acceleration
Support for OpenGL 3.0+
Support for multiple windows
Support for multiple displays
Suppor
Hi,
On 4 August 2012 12:40, Martin Schreiber wrote:
> AFAIK SDL has no high level drawing API to OpenGL, one has
> to use OpenGL directly, correct?
I haven't used SDL for graphics yet, only sound. But what you said
would kind-of defeat the point of SDL. I thought SDL is a higher level
API that
> Hmm...these horrible timings were with M$ drivers (possible s/w
> emulated OpenGL). With vedor drivers me have:
Ha ha ha, it's make us confusing. What's MS drivers did you use to
enable OpenGL 1.3? It's from NVidia or from MS?
I've experienced the same thing when running Blender on OpenSuse wit
Hmm...these horrible timings were with M$ drivers (possible s/w
emulated OpenGL). With vedor drivers me have:
===
GLView 4.0 shows:
- version v1.1..1.5
- rendering test : 150..270fps
===
and
===
C:\12>BenchSDL.exe
1/ Test : sprite
Since both SDL & SFML apps of the test start it means that OpenGL
support is present on my machine.
GLView 4.0 shows:
- version v1.1(100%) + v1.2 (12%).
- rendering test : 6fps for v1.1 & v1.2 (1.3+ are not supported)
http://www.sfml-dev.org/temp/bench-sdl-sfml.zip,
The result on my work machine (P4 2.4GHz, VGA Nvidia MX-440 64M AGP):
===
C:\12>BenchSDL.exe
1/ Test : sprites
SDL displayed 32 frames
SFML displayed 1 frames
--> SFML is 0.0x as fast as SDL // SFML doesn't
On Saturday 04 August 2012 15:45:15 Ivanko B wrote:
> For me, SFML is very fast to draw dynamic text ...
> ==
> SFML can outperform SDL+OpenGL only if the SFML guys have achieved
> excellent algorithm optimization (caching, reusing, fine tuning,..) .
>
And it would be interesting if
For me, SFML is very fast to draw dynamic text ...
==
SFML can outperform SDL+OpenGL only if the SFML guys have achieved
excellent algorithm optimization (caching, reusing, fine tuning,..) .
--
Live Securit
On Saturday 04 August 2012 14:15:45 wahono sri wrote:
> Hi Martin, did you download benchmark test from
> http://www.sfml-dev.org/temp/bench-sdl-sfml.zip, it has source and
> binary for Windows, you can run it without compiling with gcc.
>
> And you can analyze at text-dyamic.cpp, and certainly the
Hi Martin, did you download benchmark test from
http://www.sfml-dev.org/temp/bench-sdl-sfml.zip, it has source and
binary for Windows, you can run it without compiling with gcc.
And you can analyze at text-dyamic.cpp, and certainly the result of
SDL & SFML. For me, SFML is very fast to draw dynami
AFAIK SDL has no high level drawing API to OpenGL, one has
to use OpenGL directly, correct?
===
AFAIK, yes.
BTW, there is a lot of copied messages again in your mail.
==
Ohh.. me forgot to switch to the advanced mode of quick answer to
erase the auto quoting. Still th
On Saturday 04 August 2012 12:55:38 Ivanko B wrote:
> MSEgui only needs polishing to run on OpenGL (so doesn't need any
> SFML/SDL helping for it) .. its audio choice (PulseAudio) can run on
> Linux, Win-32, Android, iOS [no need in SDL/SFML for that],.. for
> networking MSEgui has the excellent Sy
MSEgui only needs polishing to run on OpenGL (so doesn't need any
SFML/SDL helping for it) .. its audio choice (PulseAudio) can run on
Linux, Win-32, Android, iOS [no need in SDL/SFML for that],.. for
networking MSEgui has the excellent Synapse [no need in SFML for
that].. correct, Martin ?
2012/
That SFML developer simply rigged the "benchmark tests" to promote the
SFML library
==
Sure since how else calling same OpenGL API through C++ could be
faster than one through pure C - almost Assembler code after compiling
:)
[everyone comparing disassembler dumps of C & C++ programs will
Hi,
On 4 August 2012 06:02, Martin Schreiber wrote:
> What would be really interesting is to see how an SDL-driven OpenGL
> application performs compared to SFML. That would be a meaningful test, for
> two reasons: it compares similar technologies and it benchmarks against SDL
> the way SDL is al
On Saturday 04 August 2012 10:43:38 Ivanko B wrote:
> mobile programming if using SDL/SFML.
> =
> ? Target CPU support in the platform-specific code ? Martin doesn't
> even have time to adopt X86_64.
>
I wrote:
"
Yes, a SDL or SFML backend for MSEgui is a possibility. Although an OS X
mobile programming if using SDL/SFML.
=
? Target CPU support in the platform-specific code ? Martin doesn't
even have time to adopt X86_64.
2012/8/4, Martin Schreiber :
> On Saturday 04 August 2012 10:04:11 Ivanko B wrote:
>> What do you think about my comment that on smartphones and
On Saturday 04 August 2012 10:04:11 Ivanko B wrote:
> What do you think about my comment that on smartphones and probably on
> other handhelds too one should use the native widget API?
>
> Hmm...it means that SFML doesn't suit since OpenGL is a requirement
> for it. SDL provides entrie
On 4 August 2012 02:24, Ivanko B wrote:
> SFML is 19.9x as fast as SDL
> ===
> It means that SDL 1.2 (as a s/w renderer by default) don't use OpenGL
> h/w accelaration in these tests
That is how I understood it too, by reading other message threads on
the internet. You ne
What do you think about my comment that on smartphones and probably on other
handhelds too one should use the native widget API?
Hmm...it means that SFML doesn't suit since OpenGL is a requirement
for it. SDL provides entries for OpenGL & DirectX and s/w rendering if
these aren't supp
41 matches
Mail list logo
