Hi,
please do someone ever see this error?
Failed to upload texture, sz 174592
Memory heap (nil):
heap == 0
End of memory blocks
It is in my OpenGL program and it throws this error when uploading
texture. (It does the same when i try to run tuxracer)
I have Matrox G400 and odd thing is that there is 10 computers with almost
the same configuration (at least graphic card and OS (RedHat 7.3) is the
same) but only on 2 computers goes eveything well on the rest is Failed to
upload texture. If i exec prog via X-forwarding then everything is ok.
Any suggestions?
Thanks Krata
I have heard of issues with loading textures larger than 256x256 through
OpenGL on certain graphics cards. I dont know if you can fix it through
software though. Try using a grpaphics card from a working PC onto one
of the non working ones. If the non working computer continues to not
work, this is not the issue.
Krata wrote:> Hi,
please do someone ever see this error?
Failed to upload texture, sz 174592
Memory heap (nil):
heap == 0
End of memory blocks
It is in my OpenGL program and it throws this error when uploading
texture. (It does the same when i try to run tuxracer)
I have Matrox G400 and odd thing is that there is 10 computers with almost
the same configuration (at least graphic card and OS (RedHat 7.3) is the
same) but only on 2 computers goes eveything well on the rest is Failed to
upload texture. If i exec prog via X-forwarding then everything is ok.
Any suggestions?
Thanks Krata
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Only 3dfx has this problem, and I believe all current 3dfx drivers hack
around the problem in some manner or other.On Thu, Aug 08, 2002 at 02:49:24PM -0500, Stanley E Brown wrote:
I have heard of issues with loading textures larger than 256x256 through
OpenGL on certain graphics cards. I dont know if you can fix it through
software though. Try using a grpaphics card from a working PC onto one
of the non working ones. If the non working computer continues to not
work, this is not the issue.
–
Joseph Carter What’re you looking at?
“Hello?” “Hi baybee” “Are you Johnie Ingram?” “For you I’ll be
anyone” “Ermm… Do you sell slink CD’s?” “I love slinkies”
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020809/761d6a9c/attachment.pgp
According to Mesa OpenGL limitations docs I actually overstated the
possible maximum:-------------
Implementations must support textures of at least 64 by 64 texels.
Larger textures are usually supported but consider the possibility that
you may be limited to 64 by 64. 512 by 512 is a common limit.
Matrox has produced alot of cheap chips and cards so I would expect the
worst.
Joseph Carter wrote:
On Thu, Aug 08, 2002 at 02:49:24PM -0500, Stanley E Brown wrote:
I have heard of issues with loading textures larger than 256x256 through
OpenGL on certain graphics cards. I dont know if you can fix it through
software though. Try using a grpaphics card from a working PC onto one
of the non working ones. If the non working computer continues to not
work, this is not the issue.
Only 3dfx has this problem, and I believe all current 3dfx drivers hack
around the problem in some manner or other.
No need to cast unfounded aspersions on Matrox. Matrox has had
problems with buggy drivers, but the cards themselves have been
reasonably functional.
No consumer 3D card that I’m aware of has ever supported less than
256x256 textures, and in fact it was Matrox who introduced ST3C
texture compression (subsequently licensed by Microsoft for Direct
3D).
With the exception of early 3dfx cards (up to and including Voodoo 3),
every consumer vendor I know of has supported at least 1024x1024
texture sizes.
You should be aware of another limitation: those same 3dfx cards also
had an aspect ratio limit of 1:8 – in other words, if you use 256 for
one dimension, the other one must be at least 16. I don’t know of any
other card that had that limitation.
One last thing: you can use glGet() to query GL_MAX_TEXTURE_SIZE,
which may return a useful value. If it’s smaller than the texture
you’re trying to upload, you can decimate your texture first. If
someone’s using a Voodoo 2, they don’t expect to see 1024 texture
resolution anyway.
Kent
Friday, August 9, 2002, 4:50:39 PM, sdl-admin wrote:> According to Mesa OpenGL limitations docs I actually overstated the
possible maximum:
Implementations must support textures of at least 64 by 64 texels.
Larger textures are usually supported but consider the possibility that
you may be limited to 64 by 64. 512 by 512 is a common limit.
Matrox has produced alot of cheap chips and cards so I would expect the
worst.
Joseph Carter wrote:
On Thu, Aug 08, 2002 at 02:49:24PM -0500, Stanley E Brown wrote:
I have heard of issues with loading textures larger than 256x256 through
OpenGL on certain graphics cards. I dont know if you can fix it through
software though. Try using a grpaphics card from a working PC onto one
of the non working ones. If the non working computer continues to not
work, this is not the issue.
Only 3dfx has this problem, and I believe all current 3dfx drivers hack
around the problem in some manner or other.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
Kent Quirk, CTO, CogniToy
@Kent_Quirk
http://www.cognitoy.com
No consumer 3D card that I’m aware of has ever supported less
than 256x256 textures, and in fact it was Matrox who
introduced ST3C texture compression (subsequently licensed by
Microsoft for Direct 3D).
Small nitpick, but it was S3 that introduced it, hence “S3TC”. Matrox
gave us EMBM.
You should be aware of another limitation: those same 3dfx
cards also had an aspect ratio limit of 1:8 – in other
Which was usually hidden by the driver, i.e. it would do relevant
padding.
One last thing: you can use glGet() to query
GL_MAX_TEXTURE_SIZE, which may return a useful value.
The other direction to go is to use texture proxies.
Brian
No need to cast unfounded aspersions on Matrox. Matrox has had
problems with buggy drivers, but the cards themselves have been
reasonably functional.
Matrox produced alot of simple PCI video cards for low cost PCs. Many
of these were not built very well and besides buggy drivers had actual
hardware flaws. I am not holding an opinion on Matrox cards but rather
stating that you sometimes get what you pay for. I will agree that the
retail Matrox cards were of much better quality and reliability.
One last thing: you can use glGet() to query GL_MAX_TEXTURE_SIZE,
which may return a useful value. If it’s smaller than the texture
The document I quoted in the last post gave another way (Ive never used
it though):
OpenGL 1.1 and the GL_EXT_texture extension offer proxy textures which
better indicate the maximum texture size than glGet.
Ah great,
thanks a lot to all but i don’t think that this is actualy this problem.
I think that cards in functional and non functional computer is the same.
(i can’t tell you for sure. It’s school computers so i can’t open it ;-( )
but cat /proc/pci at working computer
VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 4).
IRQ 11.
Master Capable. Latency=64. Min Gnt=16.Max Lat=32.
Prefetchable 32 bit memory at 0xe2000000 [0xe3ffffff].
Non-prefetchable 32 bit memory at 0xe1000000 [0xe1003fff].
Non-prefetchable 32 bit memory at 0xe0800000 [0xe0ffffff].
and cat /proc/pci at non working
VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 4).
IRQ 11.
Master Capable. Latency=64. Min Gnt=16.Max Lat=32.
Prefetchable 32 bit memory at 0xe2000000 [0xe3ffffff].
Non-prefetchable 32 bit memory at 0xe1000000 [0xe1003fff].
Non-prefetchable 32 bit memory at 0xe0800000 [0xe0ffffff].
it seems same to me. Ok maybe it doesn’t mean it has the same card, does
it?
But you are right i do not test max texture size. So it is possible that i
give larger texture then alowed. But why it is working on one and not the
another? And if it is because of large textures then TuxRacer has bug 
(i can’t test anything until i get to school. I’ll get you know after i
try)
Krata
No need to cast unfounded aspersions on Matrox. Matrox has had
problems with buggy drivers, but the cards themselves have been
reasonably functional.
Matrox produced alot of simple PCI video cards for low cost PCs. Many
of these were not built very well and besides buggy drivers had actual
hardware flaws. I am not holding an opinion on Matrox cards but rather
stating that you sometimes get what you pay for. I will agree that the
retail Matrox cards were of much better quality and reliability.
As one who did a tour for many years in BIOS, the Matrox Millenium and
that era of cards were total garbage from many perspectives. They went out
of their way to purposely misinterpret/violate the VESA spec and the PCI
specification (I.E. asking for 32 megabytes of decode space and decoding
64 megabytes, causing adjacent card access to cause the system to lock).
The number of hacks we had to do in BIOS because of their buggy products
were in the teens. Just throw Matrox cards in the trash where they belong.
–>Neil-------------------------------------------------------------------------------
Neil Bradley What are burger lovers saying
Synthcom Systems, Inc. about the new BK Back Porch Griller?
ICQ #29402898 “It tastes like it came off the back porch.” - Me
were in the teens. Just throw Matrox cards in the trash where they belong.
Or, if they are vaguely recent, and PCI, email me for the mailing
address.
(If they have TV out, I may be interested in paying a small bit.)
Zephaniah E. Hull.On Fri, Aug 09, 2002 at 03:54:22PM -0700, Neil Bradley wrote:
–>Neil
Neil Bradley What are burger lovers saying
Synthcom Systems, Inc. about the new BK Back Porch Griller?
ICQ #29402898 “It tastes like it came off the back porch.” - Me
–
1024D/E65A7801 Zephaniah E. Hull <@Zephaniah_E_Hull>
92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801
CCs of replies from mailing lists are requested.
Knghtbrd: Any suggestions on how to semi-easily make $55?
Mercury: if you went and beat the crap out of some QL people
I’m sure you’d get at least tenfold that from people
expressing their gratitude ;>
(my luck he takes that seriously hehe)
Knghtbrd: This channel is logged…
[msg(Knghtbrd)] If you can provide transportation… <=:]
[Knghtbrd(knghtbrd at adsl-63-197-120-111.dsl.sktn01.pacbell.net)] hahahaha
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020811/cb3d2629/attachment.pgp
ah floods solved (temporarily) my problems with Matrox and textures.
Krata