Interesting figures. Can you please tell us what CPU/clock frequency this
Acer has? How old is it, is it still a "current" system that may be seen
frequently?
I am again mostly off now until Thursday. Success to all developments and
speedups!
G.
On So, 9.09.2012, 04:41, Barry Gerdes wrote:
>
> H
Hi Georg
The notebook is an Acer/ N270 Atom 1GB memory 160 GB HDD. I have had it for
nearly 3 years.
I bought it at a sale in the local supermarket. I think it was a clearance on
the early N270 Atoms
I haven't got any more details without looking them up on the internet
Barry Gerdes
Beau
Ah, also an Atom, this was not clear to me. OK, I hope Ferdinand can do
something, if those CPUs are so close to ARMs.
Kind regards,
G.
On So, 9.09.2012, 12:45, Barry Gerdes wrote:
>
> Hi Georg
>
> The notebook is an Acer/ N270 Atom 1GB memory 160 GB HDD. I have had it
> for nearly 3 years.
> I
Not really close architecture-wise, just speed-wise.
ARM has its own problems that will likely come up
only once we profile on ARM
(e.g. virtual calls should be more expensive).
I'd like to eventually get it working on something like Raspberry Pi,
I think it should be possible (although that's not
Hello!
Today I tried make test build for 0.12.0 for Windows (for testers) and I
can't get a working package. On Windows 32-bit Stellarium compiles but not
work. On Windows 64-bit Stellarium not compiles.
Anybody have similar problems?
WBW, Alexander
--
Alex, what version of GCC did you use? I can build 32-bit package in
Release mode on Win7 with MinGW GCC 4.7.0 but it crashes at start up and
return code 5, build with 4.6.2 works fine. The last rev I build was 5597.
I didn't tried 64-bit build.
On Sun, Sep 9, 2012 at 10:35 PM, Alexander Wolf wrot
Gcc 4.7
WBW, Alexander
09.09.2012 21:39 пользователь "Allen Zhong" написал:
> Alex, what version of GCC did you use? I can build 32-bit package in
> Release mode on Win7 with MinGW GCC 4.7.0 but it crashes at start up and
> return code 5, build with 4.6.2 works fine. The last rev I build was 559
Build with GCC 4.7 crashes on start up since about 0.11.4 on win, my build
on linux with 4.7.1 works fine, I don't know if this is a MinGW bug. BTW,
4.6.2 always works fine on my win7.
On Sun, Sep 9, 2012 at 10:40 PM, Alexander Wolf wrote:
> Gcc 4.7
>
> WBW, Alexander
> 09.09.2012 21:39 пользоват
ok
I'm downgrade MinGW GCC to 4.4.0 and try build Stellarium.
2012/9/9 Allen Zhong :
> Build with GCC 4.7 crashes on start up since about 0.11.4 on win, my build
> on linux with 4.7.1 works fine, I don't know if this is a MinGW bug. BTW,
> 4.6.2 always works fine on my win7.
--
With best regard
I'm beginning to try & cleanup out cmake files. Some of this is just
bit-rot that has set in, but, some of this will be required for the move to Qt5.
I really do not know how useful the buildbots are; they seem to be
broken more often than not, for any number of reasons. This w
Hi,
I've been away having all the fun at Burning Man. Seen a lot of crazy
stuff. It was fun. Anyway, I'm back and I updated and built trunk.
I'm wondering if other people have the same experiences or if it's
just me:
1. I deleted my ~/.stellarium dir to get a clean config, and now I
find that
2:
Several people have reported this problem but I couldn't reproduce it yet.
Not sure what is the cause.
3:
Still working on this. We seem to get better FPS on some GPU/drivers,
worse on others. Particularly bad seem to be Atoms with integrated GPU.
What are you using (CPU/GPU/OS/driver)?
3a:
N
Hi Matthew
I get all the same problems on some computers and not others so the problems
are platform based.
At present I test on two Win 7 platforms and six XP platforms (it takes about 6
hours to do clean builds)
I also build in Linux on 3 platforms
I addition I also have virtuals on the Win 7
Hi Matthew
I missed the zoom problem
when I zoom in on solar system objects I don't have any fps problems. In fact
it is slightly faster. However the "texture" becomes a checker board
(Yellow/black).
This does not happen on all my platforms and is intermittent on some. It has to
be with i
The checkerboard is a placeholder used in case a texture failed to load
or something was unsupported. It is also used while the texture is loading.
Previously, with planets, if texture didn't load / was still loading
the planet simply wouldn't be drawn, I thought this would be better as
it is more
Hi Ferdinand
See the reason for the checker board. ( I don't like it but that is only my
opinion)
In my computers some load the textures instantaneously so they are there from
the begining. (No checker board)
Others have an onscreen load bar at the bottom RHS of screen if the texture is
still
On 9 September 2012 18:38, Ferdinand Majerech wrote:
> 3:
> Still working on this. We seem to get better FPS on some GPU/drivers,
> worse on others. Particularly bad seem to be Atoms with integrated GPU.
>
> What are you using (CPU/GPU/OS/driver)?
Kubuntu 12.04; kernel 3.2.0-29-generic-pae
Accord
17 matches
Mail list logo