network profile
| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 2 years, 2 months |
| seen | 4 hours ago | |
| stats | profile views | 16 |
|
May 18 |
revised |
Is it possible to get the colliding sides using the separating axis theorem? added 922 characters in body |
|
May 17 |
asked | Is it possible to get the colliding sides using the separating axis theorem? |
|
May 16 |
accepted | When to detect and respond to collisions? |
|
May 15 |
asked | When to detect and respond to collisions? |
|
May 8 |
comment |
OpenGL: Filtering/antialising textures in a 2D game @DevilWithin I do not store any local pixel data, I really just call glCreateTextures() etc. and then get rid of the pixmap I used to create it. I'll look into this more closely, maybe it's a leak then. |
|
May 8 |
comment |
OpenGL: Filtering/antialising textures in a 2D game @DevilWithin I preload all art for each screen, otherwise I'm seeing visible lags. Since I want to support older PCs with considerably less texture memory, I don't see that as an option. Besides, I'm not caching the pixmaps or compressed image data, I'm simply not calling glDeleteTextures. glCreateTextures seems to store things in RAM. |
|
May 8 |
comment |
OpenGL: Filtering/antialising textures in a 2D game @eBusiness Like I said, they're displayed at fixed size, determined at load time. |
|
May 8 |
comment |
OpenGL: Filtering/antialising textures in a 2D game @DevilWithin 33% more is quite a bit in my case. On a MacBook Pro Retina, I'm already at 1 GB of resident memory use for the huge artwork. Also, speculatively generating smaller images seems wasteful, I know exactly how big my texture is going to be on screen at load time. |
|
May 7 |
asked | OpenGL: Filtering/antialising textures in a 2D game |
|
May 7 |
revised |
How was traditional 2D collision detection/resolution being done? added 137 characters in body |
|
May 7 |
accepted | How was traditional 2D collision detection/resolution being done? |
|
May 7 |
comment |
How was traditional 2D collision detection/resolution being done? @DaleyPaley But how to separate for no penetration? That's the tricky part if there wasn't a standard way to calculate the time of impact (which seems to have come up in the 2000s from what I see). |
|
May 7 |
revised |
How was traditional 2D collision detection/resolution being done? edited title |
|
May 7 |
comment |
How was traditional 2D collision detection/resolution being done? And how about collision resolution/response? |
|
May 7 |
revised |
How was traditional 2D collision detection/resolution being done? added 23 characters in body |
|
May 7 |
asked | How was traditional 2D collision detection/resolution being done? |
|
Apr 22 |
comment |
How to reduce/handle image loading times? Yes, I suppose the format he suggested is an option, but I can't help but think that I'll need to load images upfront no matter how fast loading gets - I suppose it'll still be noticeable, if only on older hardware. Can't really decide if I should have a mapping as described above or just instantiate all entities upfront as much as possible. |
|
Apr 22 |
comment |
How to reduce/handle image loading times? I'd preferably stick with PNG (or any other lossless, patent-free compression format), but I'll keep S3TC in mind if I image loading times get too crazy. But I feel that, whatever I do, I'll have to load images upfront, got advice on that? |
|
Apr 21 |
comment |
How to reduce/handle image loading times? The bottleneck appears to be compression, disk I/O is too fast to be measurable (at least on my box, which has an SSD). So are you saying I should load/decompress images in advance or rather on demand? If the former, any idea how to achieve that besides having that huge mapping I mentioned above? |
|
Apr 20 |
revised |
How to reduce/handle image loading times? edited title |
