Hi,

On Sun, Apr 18, 2010 at 10:40:29PM +0200, mobi phil wrote:
> Hello,,,
> 
> 
> I think I was sending the email to the wrong address... Please consider
> following problems, and solutions...
> 
> On Sun, Apr 18, 2010 at 9:11 PM, mobi phil <[email protected]> wrote:
> 
> > Hello,
> >
> > 1. was evaluating agar, things worked fine with 1.3.X, but all the
> > test/demo apps the 1.4 crashes with following stackframe:
> >
> > #0  0x40183430 in pthread_mutex_lock () from /lib/libpthread.so.0
> > #1  0x400dd778 in AG_ObjectDetach (pChld=<value optimized out>) at
> > object.c:494
> > #2  0x4008c23c in AG_DriverClose (drv=0xd4) at drv.c:123
> > #3  0x40039b90 in AG_InitGraphics (spec=0x0) at gui.c:392
> > #4  0x00008ff0 in main (argc=1, argv=0xbeaf1cf4) at objmgr.c:38

Was this resolved?

> > 2. it is not straightforward to crosscompile... The build system is also a
> > bit strange.. Why don't you use standard autotools...

You should be able to cross-compile using the standard method of setting
the environment variables $CC, etc. to use your toolchain. What problems
are you having specifically?

The build system we are using is called BSDBuild; it is documented at:
http://bsdbuild.hypertriton.com/. It is based on the 4.4BSD build system
so it will certainly seem strange to people used to working on a GNU-style
environment, but it has many advantages over autotools.

> > 3. make -j does not work properly... it seams that you launch a make
> > process for each file, that makes make from root quite slow if only one file
> > need to be rebuild

This only occurs if you build in the source directory itself. For best
performance, try building from an external directory (see "Concurrent
building" in INSTALL).

> > the rest is the best.. I mean framework is quite promissing, intending to
> > use it for at least for proof of concept for the unfamous openmoko
> > freerunner device

Cool. I'm glad to hear that these are still around. If somebody wants to
donate a device, I'd be glad to work on a supported port.

> i found the reason in agare < 1.4, one could pass the size of the video to
> AG_InitGraphics, but with redesign that opportunity is gone..
> AG_InitGraphics (spec=0x0) at gui.c:364 tries to set it to a
> not-by-all-cards-supported-640x480 value and that makes the init fail....

You can still use AG_InitVideo() instead of AG_InitGraphics() and pass an
explicit geometry. AG_InitVideo() will only select among sdlfb and sdlgl.

> What I would suggest is to do SDL_  do SDL_GetVideoInfo() and set w and h
> attributes of the driver.....

I'm not sure about the best way to select a default resolution for
single-window drivers when AG_InitGraphics() is used. On desktops, we
wouldn't want to start full-screen, for instance. What about some %
of the full display size?


_______________________________________________
Agar mailing list
[email protected]
http://libagar.org/lists.html

Reply via email to