Showing off my flash Quake3 BSP viewer

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Showing off my flash Quake3 BSP viewer

Mario Carbajal

I've been working on it ever since I found and fell in love with HaXe a few weeks ago. I will most likely make this an open source library in the near future ( right now the code is shamefully messy ).
It differs from HxQuake in that it's using the flash drawing api instead of custom rasterization. It can only render static objects.

Please give me your thoughts about it :)


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Showing off my flash Quake3 BSP viewer

jlm@justinfront.net
Thumbs up :)

On 9 Apr 2010, at 03:32, Mario Carbajal wrote:


I've been working on it ever since I found and fell in love with HaXe a few weeks ago. I will most likely make this an open source library in the near future ( right now the code is shamefully messy ).
It differs from HxQuake in that it's using the flash drawing api instead of custom rasterization. It can only render static objects.

Please give me your thoughts about it :)

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Showing off my flash Quake3 BSP viewer

Tarwin Stroh-Spijer
Holy crap! Good work man - looks amazing!


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: +61 3 8060 5321
_______________________


On Fri, Apr 9, 2010 at 12:51 PM, Justin Lawerance Mills <[hidden email]> wrote:
Thumbs up :)

On 9 Apr 2010, at 03:32, Mario Carbajal wrote:


I've been working on it ever since I found and fell in love with HaXe a few weeks ago. I will most likely make this an open source library in the near future ( right now the code is shamefully messy ).
It differs from HxQuake in that it's using the flash drawing api instead of custom rasterization. It can only render static objects.

Please give me your thoughts about it :)

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Showing off my flash Quake3 BSP viewer

slenkar
In reply to this post by Mario Carbajal
very good,
im only using static objects for my next game
Reply | Threaded
Open this post in threaded view
|

Re: Showing off my flash Quake3 BSP viewer

badsector-2
In reply to this post by Mario Carbajal
Looks very good :-).

Can you do a second rendering pass in another bitmap to blend the textures?

Kostas

On Apr 9, 2010, at 5:32 AM, Mario Carbajal wrote:


I've been working on it ever since I found and fell in love with HaXe a few weeks ago. I will most likely make this an open source library in the near future ( right now the code is shamefully messy ).
It differs from HxQuake in that it's using the flash drawing api instead of custom rasterization. It can only render static objects.

Please give me your thoughts about it :)

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Showing off my flash Quake3 BSP viewer

Mario Carbajal
On Fri, Apr 9, 2010 at 5:31 AM, badsector <[hidden email]> wrote:
Looks very good :-).

Can you do a second rendering pass in another bitmap to blend the textures?

Kostas
 
I'll be doing that pretty soon. However, since fillrate seems to be the main bottleneck, I expect it to result in halved performance.
 

On Apr 9, 2010, at 5:32 AM, Mario Carbajal wrote:


I've been working on it ever since I found and fell in love with HaXe a few weeks ago. I will most likely make this an open source library in the near future ( right now the code is shamefully messy ).
It differs from HxQuake in that it's using the flash drawing api instead of custom rasterization. It can only render static objects.

Please give me your thoughts about it :)

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Showing off my flash Quake3 BSP viewer

badsector-2
Ι would render the lightmaps in 50% or 25% resolution and upscale them :-)

On Apr 9, 2010, at 3:30 PM, Mario Carbajal wrote:

On Fri, Apr 9, 2010 at 5:31 AM, badsector <[hidden email]> wrote:
Looks very good :-).

Can you do a second rendering pass in another bitmap to blend the textures?

Kostas
 
I'll be doing that pretty soon. However, since fillrate seems to be the main bottleneck, I expect it to result in halved performance.
 

On Apr 9, 2010, at 5:32 AM, Mario Carbajal wrote:


I've been working on it ever since I found and fell in love with HaXe a few weeks ago. I will most likely make this an open source library in the near future ( right now the code is shamefully messy ).
It differs from HxQuake in that it's using the flash drawing api instead of custom rasterization. It can only render static objects.

Please give me your thoughts about it :)

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Showing off my flash Quake3 BSP viewer

Mario Carbajal
On Fri, Apr 9, 2010 at 10:39 AM, badsector <[hidden email]> wrote:
Ι would render the lightmaps in 50% or 25% resolution and upscale them :-)

Thats a good idea, I'll have to experiment with that. Thanks :) 

On Apr 9, 2010, at 3:30 PM, Mario Carbajal wrote:

On Fri, Apr 9, 2010 at 5:31 AM, badsector <[hidden email]> wrote:
Looks very good :-).

Can you do a second rendering pass in another bitmap to blend the textures?

Kostas
 
I'll be doing that pretty soon. However, since fillrate seems to be the main bottleneck, I expect it to result in halved performance.
 

On Apr 9, 2010, at 5:32 AM, Mario Carbajal wrote:


I've been working on it ever since I found and fell in love with HaXe a few weeks ago. I will most likely make this an open source library in the near future ( right now the code is shamefully messy ).
It differs from HxQuake in that it's using the flash drawing api instead of custom rasterization. It can only render static objects.

Please give me your thoughts about it :)

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Showing off my flash Quake3 BSP viewer

Iain Surgey
In reply to this post by Mario Carbajal
Have you thought about mip-mapping? It should reduce the fill area a lot for distant surfaces and doesn't require much more texture memory.

Great work BTW.

On 9 April 2010 13:30, Mario Carbajal <[hidden email]> wrote:
On Fri, Apr 9, 2010 at 5:31 AM, badsector <[hidden email]> wrote:
Looks very good :-).

Can you do a second rendering pass in another bitmap to blend the textures?

Kostas
 
I'll be doing that pretty soon. However, since fillrate seems to be the main bottleneck, I expect it to result in halved performance.
 

On Apr 9, 2010, at 5:32 AM, Mario Carbajal wrote:


I've been working on it ever since I found and fell in love with HaXe a few weeks ago. I will most likely make this an open source library in the near future ( right now the code is shamefully messy ).
It differs from HxQuake in that it's using the flash drawing api instead of custom rasterization. It can only render static objects.

Please give me your thoughts about it :)

--
haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Showing off my flash Quake3 BSP viewer

Mario Carbajal
On Sat, Apr 10, 2010 at 12:53 PM, Iain Surgey <[hidden email]> wrote:
Have you thought about mip-mapping? It should reduce the fill area a lot for distant surfaces and doesn't require much more texture memory.

I have thought of implementing some sort of mip-mapping, yes. But I don't see how it would reduce the fill area since the size of the triangles I would render is unaffected. ( please correct me if I'm wrong )
Mip-mapping can improve performance because smaller textures are nicer to the cache, but I'm not sure how much this would affect the flash drawing api performance.
The main advantage I see for mip-mapping is that it reduces aliasing of the texture contents when the polygons are small.

Btw, I now have both textures and lightmaps being displayed, I'll probably upload a new demo with that soon. :)

Great work BTW.

On 9 April 2010 13:30, Mario Carbajal <[hidden email]> wrote:
On Fri, Apr 9, 2010 at 5:31 AM, badsector <[hidden email]> wrote:
Looks very good :-).

Can you do a second rendering pass in another bitmap to blend the textures?

Kostas
 
I'll be doing that pretty soon. However, since fillrate seems to be the main bottleneck, I expect it to result in halved performance.
 

On Apr 9, 2010, at 5:32 AM, Mario Carbajal wrote:


I've been working on it ever since I found and fell in love with HaXe a few weeks ago. I will most likely make this an open source library in the near future ( right now the code is shamefully messy ).
It differs from HxQuake in that it's using the flash drawing api instead of custom rasterization. It can only render static objects.

Please give me your thoughts about it :)

--
haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Showing off my flash Quake3 BSP viewer

Iain Surgey
I was more meaning for blending textures with the lightmaps than for the drawing api. Looking forward to seeing the texture mapped version :)

On 10 April 2010 17:56, Mario Carbajal <[hidden email]> wrote:
On Sat, Apr 10, 2010 at 12:53 PM, Iain Surgey <[hidden email]> wrote:
Have you thought about mip-mapping? It should reduce the fill area a lot for distant surfaces and doesn't require much more texture memory.

I have thought of implementing some sort of mip-mapping, yes. But I don't see how it would reduce the fill area since the size of the triangles I would render is unaffected. ( please correct me if I'm wrong )
Mip-mapping can improve performance because smaller textures are nicer to the cache, but I'm not sure how much this would affect the flash drawing api performance.
The main advantage I see for mip-mapping is that it reduces aliasing of the texture contents when the polygons are small.

Btw, I now have both textures and lightmaps being displayed, I'll probably upload a new demo with that soon. :)

Great work BTW.

On 9 April 2010 13:30, Mario Carbajal <[hidden email]> wrote:
On Fri, Apr 9, 2010 at 5:31 AM, badsector <[hidden email]> wrote:
Looks very good :-).

Can you do a second rendering pass in another bitmap to blend the textures?

Kostas
 
I'll be doing that pretty soon. However, since fillrate seems to be the main bottleneck, I expect it to result in halved performance.
 

On Apr 9, 2010, at 5:32 AM, Mario Carbajal wrote:


I've been working on it ever since I found and fell in love with HaXe a few weeks ago. I will most likely make this an open source library in the near future ( right now the code is shamefully messy ).
It differs from HxQuake in that it's using the flash drawing api instead of custom rasterization. It can only render static objects.

Please give me your thoughts about it :)

--
haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Showing off my flash Quake3 BSP viewer

Iain Surgey
Sorry I mis-understood. I thought you were blending the lightmaps and textures before passing the result to drawTriangles.

On 10 April 2010 18:07, Iain Surgey <[hidden email]> wrote:
I was more meaning for blending textures with the lightmaps than for the drawing api. Looking forward to seeing the texture mapped version :)

On 10 April 2010 17:56, Mario Carbajal <[hidden email]> wrote:
On Sat, Apr 10, 2010 at 12:53 PM, Iain Surgey <[hidden email]> wrote:
Have you thought about mip-mapping? It should reduce the fill area a lot for distant surfaces and doesn't require much more texture memory.

I have thought of implementing some sort of mip-mapping, yes. But I don't see how it would reduce the fill area since the size of the triangles I would render is unaffected. ( please correct me if I'm wrong )
Mip-mapping can improve performance because smaller textures are nicer to the cache, but I'm not sure how much this would affect the flash drawing api performance.
The main advantage I see for mip-mapping is that it reduces aliasing of the texture contents when the polygons are small.

Btw, I now have both textures and lightmaps being displayed, I'll probably upload a new demo with that soon. :)

Great work BTW.

On 9 April 2010 13:30, Mario Carbajal <[hidden email]> wrote:
On Fri, Apr 9, 2010 at 5:31 AM, badsector <[hidden email]> wrote:
Looks very good :-).

Can you do a second rendering pass in another bitmap to blend the textures?

Kostas
 
I'll be doing that pretty soon. However, since fillrate seems to be the main bottleneck, I expect it to result in halved performance.
 

On Apr 9, 2010, at 5:32 AM, Mario Carbajal wrote:


I've been working on it ever since I found and fell in love with HaXe a few weeks ago. I will most likely make this an open source library in the near future ( right now the code is shamefully messy ).
It differs from HxQuake in that it's using the flash drawing api instead of custom rasterization. It can only render static objects.

Please give me your thoughts about it :)

--
haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org



--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Showing off my flash Quake3 BSP viewer

Mario Carbajal
Here's an update with texture rendering:

badsector:
I tried your idea of rendering the lightmap onto a smaller buffer than the textures but unfortunately it looked only slightly better than if both were rendered in low resolution buffers.

On Sat, Apr 10, 2010 at 2:12 PM, Iain Surgey <[hidden email]> wrote:
Sorry I mis-understood. I thought you were blending the lightmaps and textures before passing the result to drawTriangles.

On 10 April 2010 18:07, Iain Surgey <[hidden email]> wrote:
I was more meaning for blending textures with the lightmaps than for the drawing api. Looking forward to seeing the texture mapped version :)

On 10 April 2010 17:56, Mario Carbajal <[hidden email]> wrote:
On Sat, Apr 10, 2010 at 12:53 PM, Iain Surgey <[hidden email]> wrote:
Have you thought about mip-mapping? It should reduce the fill area a lot for distant surfaces and doesn't require much more texture memory.

I have thought of implementing some sort of mip-mapping, yes. But I don't see how it would reduce the fill area since the size of the triangles I would render is unaffected. ( please correct me if I'm wrong )
Mip-mapping can improve performance because smaller textures are nicer to the cache, but I'm not sure how much this would affect the flash drawing api performance.
The main advantage I see for mip-mapping is that it reduces aliasing of the texture contents when the polygons are small.

Btw, I now have both textures and lightmaps being displayed, I'll probably upload a new demo with that soon. :)

Great work BTW.

On 9 April 2010 13:30, Mario Carbajal <[hidden email]> wrote:
On Fri, Apr 9, 2010 at 5:31 AM, badsector <[hidden email]> wrote:
Looks very good :-).

Can you do a second rendering pass in another bitmap to blend the textures?

Kostas
 
I'll be doing that pretty soon. However, since fillrate seems to be the main bottleneck, I expect it to result in halved performance.
 

On Apr 9, 2010, at 5:32 AM, Mario Carbajal wrote:


I've been working on it ever since I found and fell in love with HaXe a few weeks ago. I will most likely make this an open source library in the near future ( right now the code is shamefully messy ).
It differs from HxQuake in that it's using the flash drawing api instead of custom rasterization. It can only render static objects.

Please give me your thoughts about it :)

--
haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org



--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Showing off my flash Quake3 BSP viewer

Franco Ponticelli
Awesome! Congratulations.

Franco.

On Fri, Apr 16, 2010 at 1:02 AM, Mario Carbajal <[hidden email]> wrote:
Here's an update with texture rendering:

badsector:
I tried your idea of rendering the lightmap onto a smaller buffer than the textures but unfortunately it looked only slightly better than if both were rendered in low resolution buffers.

On Sat, Apr 10, 2010 at 2:12 PM, Iain Surgey <[hidden email]> wrote:
Sorry I mis-understood. I thought you were blending the lightmaps and textures before passing the result to drawTriangles.

On 10 April 2010 18:07, Iain Surgey <[hidden email]> wrote:
I was more meaning for blending textures with the lightmaps than for the drawing api. Looking forward to seeing the texture mapped version :)

On 10 April 2010 17:56, Mario Carbajal <[hidden email]> wrote:
On Sat, Apr 10, 2010 at 12:53 PM, Iain Surgey <[hidden email]> wrote:
Have you thought about mip-mapping? It should reduce the fill area a lot for distant surfaces and doesn't require much more texture memory.

I have thought of implementing some sort of mip-mapping, yes. But I don't see how it would reduce the fill area since the size of the triangles I would render is unaffected. ( please correct me if I'm wrong )
Mip-mapping can improve performance because smaller textures are nicer to the cache, but I'm not sure how much this would affect the flash drawing api performance.
The main advantage I see for mip-mapping is that it reduces aliasing of the texture contents when the polygons are small.

Btw, I now have both textures and lightmaps being displayed, I'll probably upload a new demo with that soon. :)

Great work BTW.

On 9 April 2010 13:30, Mario Carbajal <[hidden email]> wrote:
On Fri, Apr 9, 2010 at 5:31 AM, badsector <[hidden email]> wrote:
Looks very good :-).

Can you do a second rendering pass in another bitmap to blend the textures?

Kostas
 
I'll be doing that pretty soon. However, since fillrate seems to be the main bottleneck, I expect it to result in halved performance.
 

On Apr 9, 2010, at 5:32 AM, Mario Carbajal wrote:


I've been working on it ever since I found and fell in love with HaXe a few weeks ago. I will most likely make this an open source library in the near future ( right now the code is shamefully messy ).
It differs from HxQuake in that it's using the flash drawing api instead of custom rasterization. It can only render static objects.

Please give me your thoughts about it :)

--
haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org



--

haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Showing off my flash Quake3 BSP viewer

gershon
The problem with textures in flash (IMHO) is actually the lack of texture filters, as best as i can remember, Alternativa3D has a bilinear filter when the camera is still...

On Fri, Apr 16, 2010 at 12:45 PM, Franco Ponticelli <[hidden email]> wrote:
Awesome! Congratulations.

Franco.

On Fri, Apr 16, 2010 at 1:02 AM, Mario Carbajal <[hidden email]> wrote:
Here's an update with texture rendering:

badsector:
I tried your idea of rendering the lightmap onto a smaller buffer than the textures but unfortunately it looked only slightly better than if both were rendered in low resolution buffers.

On Sat, Apr 10, 2010 at 2:12 PM, Iain Surgey <[hidden email]> wrote:
Sorry I mis-understood. I thought you were blending the lightmaps and textures before passing the result to drawTriangles.

On 10 April 2010 18:07, Iain Surgey <[hidden email]> wrote:
I was more meaning for blending textures with the lightmaps than for the drawing api. Looking forward to seeing the texture mapped version :)

On 10 April 2010 17:56, Mario Carbajal <[hidden email]> wrote:
On Sat, Apr 10, 2010 at 12:53 PM, Iain Surgey <[hidden email]> wrote:
Have you thought about mip-mapping? It should reduce the fill area a lot for distant surfaces and doesn't require much more texture memory.

I have thought of implementing some sort of mip-mapping, yes. But I don't see how it would reduce the fill area since the size of the triangles I would render is unaffected. ( please correct me if I'm wrong )
Mip-mapping can improve performance because smaller textures are nicer to the cache, but I'm not sure how much this would affect the flash drawing api performance.
The main advantage I see for mip-mapping is that it reduces aliasing of the texture contents when the polygons are small.

Btw, I now have both textures and lightmaps being displayed, I'll probably upload a new demo with that soon. :)

Great work BTW.

On 9 April 2010 13:30, Mario Carbajal <[hidden email]> wrote:
On Fri, Apr 9, 2010 at 5:31 AM, badsector <[hidden email]> wrote:
Looks very good :-).

Can you do a second rendering pass in another bitmap to blend the textures?

Kostas
 
I'll be doing that pretty soon. However, since fillrate seems to be the main bottleneck, I expect it to result in halved performance.
 

On Apr 9, 2010, at 5:32 AM, Mario Carbajal wrote:


I've been working on it ever since I found and fell in love with HaXe a few weeks ago. I will most likely make this an open source library in the near future ( right now the code is shamefully messy ).
It differs from HxQuake in that it's using the flash drawing api instead of custom rasterization. It can only render static objects.

Please give me your thoughts about it :)

--
haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org



--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Showing off my flash Quake3 BSP viewer

gershon
sorry for the double-post, Awesome stuff man!!

On Fri, Apr 16, 2010 at 12:49 PM, gershon <[hidden email]> wrote:
The problem with textures in flash (IMHO) is actually the lack of texture filters, as best as i can remember, Alternativa3D has a bilinear filter when the camera is still...

On Fri, Apr 16, 2010 at 12:45 PM, Franco Ponticelli <[hidden email]> wrote:
Awesome! Congratulations.

Franco.

On Fri, Apr 16, 2010 at 1:02 AM, Mario Carbajal <[hidden email]> wrote:
Here's an update with texture rendering:

badsector:
I tried your idea of rendering the lightmap onto a smaller buffer than the textures but unfortunately it looked only slightly better than if both were rendered in low resolution buffers.

On Sat, Apr 10, 2010 at 2:12 PM, Iain Surgey <[hidden email]> wrote:
Sorry I mis-understood. I thought you were blending the lightmaps and textures before passing the result to drawTriangles.

On 10 April 2010 18:07, Iain Surgey <[hidden email]> wrote:
I was more meaning for blending textures with the lightmaps than for the drawing api. Looking forward to seeing the texture mapped version :)

On 10 April 2010 17:56, Mario Carbajal <[hidden email]> wrote:
On Sat, Apr 10, 2010 at 12:53 PM, Iain Surgey <[hidden email]> wrote:
Have you thought about mip-mapping? It should reduce the fill area a lot for distant surfaces and doesn't require much more texture memory.

I have thought of implementing some sort of mip-mapping, yes. But I don't see how it would reduce the fill area since the size of the triangles I would render is unaffected. ( please correct me if I'm wrong )
Mip-mapping can improve performance because smaller textures are nicer to the cache, but I'm not sure how much this would affect the flash drawing api performance.
The main advantage I see for mip-mapping is that it reduces aliasing of the texture contents when the polygons are small.

Btw, I now have both textures and lightmaps being displayed, I'll probably upload a new demo with that soon. :)

Great work BTW.

On 9 April 2010 13:30, Mario Carbajal <[hidden email]> wrote:
On Fri, Apr 9, 2010 at 5:31 AM, badsector <[hidden email]> wrote:
Looks very good :-).

Can you do a second rendering pass in another bitmap to blend the textures?

Kostas
 
I'll be doing that pretty soon. However, since fillrate seems to be the main bottleneck, I expect it to result in halved performance.
 

On Apr 9, 2010, at 5:32 AM, Mario Carbajal wrote:


I've been working on it ever since I found and fell in love with HaXe a few weeks ago. I will most likely make this an open source library in the near future ( right now the code is shamefully messy ).
It differs from HxQuake in that it's using the flash drawing api instead of custom rasterization. It can only render static objects.

Please give me your thoughts about it :)

--
haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org



--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org



--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Showing off my flash Quake3 BSP viewer

Andy Li
In reply to this post by gershon
Isn't scaling the bitmap with smooth set to true is the same as bilinear filter?
I've made a bicubic filter in pixelbender too, although it only works for upscaling and is pretty slow...

Andy

On Fri, Apr 16, 2010 at 5:49 PM, gershon <[hidden email]> wrote:
The problem with textures in flash (IMHO) is actually the lack of texture filters, as best as i can remember, Alternativa3D has a bilinear filter when the camera is still...

On Fri, Apr 16, 2010 at 12:45 PM, Franco Ponticelli <[hidden email]> wrote:
Awesome! Congratulations.

Franco.

On Fri, Apr 16, 2010 at 1:02 AM, Mario Carbajal <[hidden email]> wrote:
Here's an update with texture rendering:

badsector:
I tried your idea of rendering the lightmap onto a smaller buffer than the textures but unfortunately it looked only slightly better than if both were rendered in low resolution buffers.

On Sat, Apr 10, 2010 at 2:12 PM, Iain Surgey <[hidden email]> wrote:
Sorry I mis-understood. I thought you were blending the lightmaps and textures before passing the result to drawTriangles.

On 10 April 2010 18:07, Iain Surgey <[hidden email]> wrote:
I was more meaning for blending textures with the lightmaps than for the drawing api. Looking forward to seeing the texture mapped version :)

On 10 April 2010 17:56, Mario Carbajal <[hidden email]> wrote:
On Sat, Apr 10, 2010 at 12:53 PM, Iain Surgey <[hidden email]> wrote:
Have you thought about mip-mapping? It should reduce the fill area a lot for distant surfaces and doesn't require much more texture memory.

I have thought of implementing some sort of mip-mapping, yes. But I don't see how it would reduce the fill area since the size of the triangles I would render is unaffected. ( please correct me if I'm wrong )
Mip-mapping can improve performance because smaller textures are nicer to the cache, but I'm not sure how much this would affect the flash drawing api performance.
The main advantage I see for mip-mapping is that it reduces aliasing of the texture contents when the polygons are small.

Btw, I now have both textures and lightmaps being displayed, I'll probably upload a new demo with that soon. :)

Great work BTW.

On 9 April 2010 13:30, Mario Carbajal <[hidden email]> wrote:
On Fri, Apr 9, 2010 at 5:31 AM, badsector <[hidden email]> wrote:
Looks very good :-).

Can you do a second rendering pass in another bitmap to blend the textures?

Kostas
 
I'll be doing that pretty soon. However, since fillrate seems to be the main bottleneck, I expect it to result in halved performance.
 

On Apr 9, 2010, at 5:32 AM, Mario Carbajal wrote:


I've been working on it ever since I found and fell in love with HaXe a few weeks ago. I will most likely make this an open source library in the near future ( right now the code is shamefully messy ).
It differs from HxQuake in that it's using the flash drawing api instead of custom rasterization. It can only render static objects.

Please give me your thoughts about it :)

--
haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org



--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Showing off my flash Quake3 BSP viewer

Mario Carbajal
The problem with textures in flash (IMHO) is actually the lack of texture filters, as best as i can remember, Alternativa3D has a bilinear filter when the camera is still...

Actually, drawTriangles has a "smooth" parameter, which when set to true it renders the texture with some sort of billinear interpolation, but its really slow, so I disabled it. Alternativa3D is probably enabling that when the scene is still.

On Fri, Apr 16, 2010 at 10:59 AM, Andy Li <[hidden email]> wrote:
Isn't scaling the bitmap with smooth set to true is the same as bilinear filter?
I've made a bicubic filter in pixelbender too, although it only works for upscaling and is pretty slow...

Andy

On Fri, Apr 16, 2010 at 5:49 PM, gershon <[hidden email]> wrote:
The problem with textures in flash (IMHO) is actually the lack of texture filters, as best as i can remember, Alternativa3D has a bilinear filter when the camera is still...

On Fri, Apr 16, 2010 at 12:45 PM, Franco Ponticelli <[hidden email]> wrote:
Awesome! Congratulations.

Franco.

On Fri, Apr 16, 2010 at 1:02 AM, Mario Carbajal <[hidden email]> wrote:
Here's an update with texture rendering:

badsector:
I tried your idea of rendering the lightmap onto a smaller buffer than the textures but unfortunately it looked only slightly better than if both were rendered in low resolution buffers.

On Sat, Apr 10, 2010 at 2:12 PM, Iain Surgey <[hidden email]> wrote:
Sorry I mis-understood. I thought you were blending the lightmaps and textures before passing the result to drawTriangles.

On 10 April 2010 18:07, Iain Surgey <[hidden email]> wrote:
I was more meaning for blending textures with the lightmaps than for the drawing api. Looking forward to seeing the texture mapped version :)

On 10 April 2010 17:56, Mario Carbajal <[hidden email]> wrote:
On Sat, Apr 10, 2010 at 12:53 PM, Iain Surgey <[hidden email]> wrote:
Have you thought about mip-mapping? It should reduce the fill area a lot for distant surfaces and doesn't require much more texture memory.

I have thought of implementing some sort of mip-mapping, yes. But I don't see how it would reduce the fill area since the size of the triangles I would render is unaffected. ( please correct me if I'm wrong )
Mip-mapping can improve performance because smaller textures are nicer to the cache, but I'm not sure how much this would affect the flash drawing api performance.
The main advantage I see for mip-mapping is that it reduces aliasing of the texture contents when the polygons are small.

Btw, I now have both textures and lightmaps being displayed, I'll probably upload a new demo with that soon. :)

Great work BTW.

On 9 April 2010 13:30, Mario Carbajal <[hidden email]> wrote:
On Fri, Apr 9, 2010 at 5:31 AM, badsector <[hidden email]> wrote:
Looks very good :-).

Can you do a second rendering pass in another bitmap to blend the textures?

Kostas
 
I'll be doing that pretty soon. However, since fillrate seems to be the main bottleneck, I expect it to result in halved performance.
 

On Apr 9, 2010, at 5:32 AM, Mario Carbajal wrote:


I've been working on it ever since I found and fell in love with HaXe a few weeks ago. I will most likely make this an open source library in the near future ( right now the code is shamefully messy ).
It differs from HxQuake in that it's using the flash drawing api instead of custom rasterization. It can only render static objects.

Please give me your thoughts about it :)

--
haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org



--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Showing off my flash Quake3 BSP viewer

badsector-2
In reply to this post by Mario Carbajal
Hi

Here's an update with texture rendering:

It looks very good. About 25-30fps here :-).

badsector:
I tried your idea of rendering the lightmap onto a smaller buffer than the textures but unfortunately it looked only slightly better than if both were rendered in low resolution buffers.

Well i don't know how you're rendering the scene :-P. I assumed that you do something like
1. Render the scene using texture mapped triangles in bitmap buffer A
2. Render the scene using lightmapped triangles in bitmap buffer B
3. Display buffer A
4. Display buffer B blended on top of buffer A

(of course 1 and 3 can be mixed, but i see you're rendering in a buffer anyway since in fullscreen the triangles do not scale)

So what i meant was a slightly modification
1. Render the scene using texture mapped triangles in bitmap buffer A
2. Render the scene using lightmapped triangles in bitmap buffer B which has size A_width/2 and B_width/2
3. Display buffer A
4. Display buffer B blended on top of buffer A and stretched to A's size with bilinear filtering

The idea is to avoid the extra triangle fill operations (which are still done in CPU) when rendering the lightmaps, which in Quake 3 are very low resolution and the worst you'll get is a little light bleeding in edges (of course depending on what you want to do this might not be acceptable :-).

On Sat, Apr 10, 2010 at 2:12 PM, Iain Surgey <[hidden email]> wrote:
Sorry I mis-understood. I thought you were blending the lightmaps and textures before passing the result to drawTriangles.

On 10 April 2010 18:07, Iain Surgey <[hidden email]> wrote:
I was more meaning for blending textures with the lightmaps than for the drawing api. Looking forward to seeing the texture mapped version :)

On 10 April 2010 17:56, Mario Carbajal <[hidden email]> wrote:
On Sat, Apr 10, 2010 at 12:53 PM, Iain Surgey <[hidden email]> wrote:
Have you thought about mip-mapping? It should reduce the fill area a lot for distant surfaces and doesn't require much more texture memory.

I have thought of implementing some sort of mip-mapping, yes. But I don't see how it would reduce the fill area since the size of the triangles I would render is unaffected. ( please correct me if I'm wrong )
Mip-mapping can improve performance because smaller textures are nicer to the cache, but I'm not sure how much this would affect the flash drawing api performance.
The main advantage I see for mip-mapping is that it reduces aliasing of the texture contents when the polygons are small.

Btw, I now have both textures and lightmaps being displayed, I'll probably upload a new demo with that soon. :)

Great work BTW.

On 9 April 2010 13:30, Mario Carbajal <[hidden email]> wrote:
On Fri, Apr 9, 2010 at 5:31 AM, badsector <[hidden email]> wrote:
Looks very good :-).

Can you do a second rendering pass in another bitmap to blend the textures?

Kostas
 
I'll be doing that pretty soon. However, since fillrate seems to be the main bottleneck, I expect it to result in halved performance.
 

On Apr 9, 2010, at 5:32 AM, Mario Carbajal wrote:


I've been working on it ever since I found and fell in love with HaXe a few weeks ago. I will most likely make this an open source library in the near future ( right now the code is shamefully messy ).
It differs from HxQuake in that it's using the flash drawing api instead of custom rasterization. It can only render static objects.

Please give me your thoughts about it :)

--
haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org



--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Showing off my flash Quake3 BSP viewer

Correa Diego
i will use it as a stove on cold days.
;)

i like it. neat.

2010/4/16 badsector <[hidden email]>
Hi
It looks very good. About 25-30fps here :-).

badsector:
I tried your idea of rendering the lightmap onto a smaller buffer than the textures but unfortunately it looked only slightly better than if both were rendered in low resolution buffers.

Well i don't know how you're rendering the scene :-P. I assumed that you do something like
1. Render the scene using texture mapped triangles in bitmap buffer A
2. Render the scene using lightmapped triangles in bitmap buffer B
3. Display buffer A
4. Display buffer B blended on top of buffer A

(of course 1 and 3 can be mixed, but i see you're rendering in a buffer anyway since in fullscreen the triangles do not scale)

So what i meant was a slightly modification
1. Render the scene using texture mapped triangles in bitmap buffer A
2. Render the scene using lightmapped triangles in bitmap buffer B which has size A_width/2 and B_width/2
3. Display buffer A
4. Display buffer B blended on top of buffer A and stretched to A's size with bilinear filtering

The idea is to avoid the extra triangle fill operations (which are still done in CPU) when rendering the lightmaps, which in Quake 3 are very low resolution and the worst you'll get is a little light bleeding in edges (of course depending on what you want to do this might not be acceptable :-).

On Sat, Apr 10, 2010 at 2:12 PM, Iain Surgey <[hidden email]> wrote:
Sorry I mis-understood. I thought you were blending the lightmaps and textures before passing the result to drawTriangles.

On 10 April 2010 18:07, Iain Surgey <[hidden email]> wrote:
I was more meaning for blending textures with the lightmaps than for the drawing api. Looking forward to seeing the texture mapped version :)

On 10 April 2010 17:56, Mario Carbajal <[hidden email]> wrote:
On Sat, Apr 10, 2010 at 12:53 PM, Iain Surgey <[hidden email]> wrote:
Have you thought about mip-mapping? It should reduce the fill area a lot for distant surfaces and doesn't require much more texture memory.

I have thought of implementing some sort of mip-mapping, yes. But I don't see how it would reduce the fill area since the size of the triangles I would render is unaffected. ( please correct me if I'm wrong )
Mip-mapping can improve performance because smaller textures are nicer to the cache, but I'm not sure how much this would affect the flash drawing api performance.
The main advantage I see for mip-mapping is that it reduces aliasing of the texture contents when the polygons are small.

Btw, I now have both textures and lightmaps being displayed, I'll probably upload a new demo with that soon. :)

Great work BTW.

On 9 April 2010 13:30, Mario Carbajal <[hidden email]> wrote:
On Fri, Apr 9, 2010 at 5:31 AM, badsector <[hidden email]> wrote:
Looks very good :-).

Can you do a second rendering pass in another bitmap to blend the textures?

Kostas
 
I'll be doing that pretty soon. However, since fillrate seems to be the main bottleneck, I expect it to result in halved performance.
 

On Apr 9, 2010, at 5:32 AM, Mario Carbajal wrote:


I've been working on it ever since I found and fell in love with HaXe a few weeks ago. I will most likely make this an open source library in the near future ( right now the code is shamefully messy ).
It differs from HxQuake in that it's using the flash drawing api instead of custom rasterization. It can only render static objects.

Please give me your thoughts about it :)

--
haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org


--

haXe - an open source web programming language
http://haxe.org



--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org



--
http://labormedia.cl/algoritmia

--
haXe - an open source web programming language
http://haxe.org
12