Image (text) ticker implementation?

Game Play & Game Design
#1

How would you implement an image ticker scroller, I mean the proper way from the 3d resource point of view?

I have done an image ticker without 3d stuff. Moving images in a window bottom like a news ticker is not hard in a true 2D drawing. Each image takes an exact size and moves from right to left in a nice queue.

But using 3D stuff we must consider resource allocation, remember pow-2 texture size. If I had a long text string rendered to a png image 920x50px size, its quite nasty to create a texture from it. And I have two to twenty of them in a scroller data.

Screen size: 800x600
scroller height: 50px

scroll1 width 920px -> 1024x64 texture
scroll2 width 420px -> 512x64 texture
scroll3 width 1240px -> 2048x64 texture
and so on longer text strings start to grow out the roof.

I was thinking of few optimizations:
a) split longer data images to two or more textures, create sprite objects. Animate sprites to move across the window.

b) create one texture a size of the scroll area (1024x64) minimum, do not move texture but update pixel content at runtime to simulate data images scrolling across the window.

Any first-hand tips and experience any of you?

#2

Fill 1 texture will the first 256 characters (16x16 tiles)

Then use java.awt.FontMetrics to position your quads.

Constant memory usage, no matter what the text length is.

#3

Problem is I need to use a full unicode range, not just common known letters. And image may have one or two graphics images, bullets, effects and smileys so on… So I was thinking of creating plain 2d images using drawing api and scroller does not see texts as text but a ready to use image file.

#4

Then you can use the texture as a cache of 256 characters. I doubt 1 ticker-item will use more than 256 unique characters.
Just in case, make the texture bigger, and use a cache of 512 or 1024 characters. You keep streaming new characters to the texture when required.

Then again, just drawing everything in Java2D, you’ll not have any problems with large textures until you hit 4096px (or so), although you probably want to chop your textures into 256px anyway, to keep things managable.

If you have a group of ~6 textures of 256px (depending on the resolution width), and every texture that scrolls out of view is repositioned at the other side, you can just copy java.awt.Images from Java2D into those small textures. Then your drawing logic will be fully in Java2D (which is probably a good thing) and you only need to call g.translate(x,y) to draw the right part of the text in the Image (which is also 256px), which will be fully copied to the texture.

#5

(follow-up post)
This is what I have done now, I made a test with Delphi+DX but similar technique should apply to JOGL/LWJGL 3d apps.

  • create and render texts using a regular 2d drawing apis, no 3D is used here.

  • split and save ARGB bitmaps to 256x64 image_XXX.png files

  • create six 256x64 textures, just to fill entire scrolling width plus few extras

  • bind first six bitmap memory buffers to texture objects and start scrolling

  • when leading texture goes leftside offscreen, move it to the end of list and bind next pending memory buffer on it

  • keep scrolling, move to the end, bind next memory buffer

Now I can run unlimited number of images, be it textTobitmap, bulleting icons anything and use six fixed-size textures. Nice. Testscroller.exe takes 0-1 CPU% in a low-end laptop so am happy.

edit: testcroller.exe is using DX vertex buffers, I found out directx IDSprite interface did not give smooth enough animations.

I can vsync windowed DirectX9 application so scrolling is close to a ultra smooth. I believe this is going to be a major Java problem.

Working vsync is close to impossible in windowed Java application?
I am more than pleased to see examples if there are methods to make ultra smooth windowed animation.