SetColorMod() with mini delay when the texture is rendered for the first time

Game Development
1

Hi, this is my first post. I wasn’t sure if this was the appropriate place or SDL development.

I have one image.png that I load using SDL_IMG. I load by creating a surface. Then I create a texture using CreateTextureFromSurface() and I free the original surface. I repeat the same process but now at the end I use SetColorMod(128, 128, 0) to this new texture. This changes the color of the image as I wanted! Cool!

This whole process is done way before the images are rendered to the screen. The original texture (without the color change) is rendered normally. The texture with the color change creates a mini delay when rendered for the first time. After that it keeps rendering without any delay.

Has anyone experienced this or have any idea on what is going on? I’m using SDL 2.0.2 (I’m using ubuntu 14.04)

2

Hi tupan,
think this place is good. SDL-Dev is more about coding on SDL not with.
Actually you don’t need to free the surface all the time. Put it into clean_up().

I am very carefully claiming “you do it wrong” =)

  • can I see the code?

-Cass

3

Hi, Acry! Thanks for the response. I forgot to mention that I’m using Go (https://github.com/veandco/go-sdl2) to write the code, not C or C++. I’m not sure how familiar you are with go but for clarity when there is a colon followed by a equal sign, it means that it is declaring and allocating memory for that memory in one line.

this part of the code on how I load the (I also do some checking such as if file exist, errors when loading to the surface… I’m not putting it here). You can see more the repository https://github.com/tubelz/macaw this part would be in the files entity/spritesheet.go and system/render.go

// load function
func load() {
    newSurface, err = img.Load(fname)
    defer newSurface.Free()
    newTexture, err = renderer.CreateTextureFromSurface(newSurface)
    return newTexture
}

// pre load
func init() {
    sprite1 := load()
    
    sprite2 := load()
    sprite2.SetColorMod(128, 128, 0)
}

// render...
func render() {
    Renderer.Clear()
    //loop for each object
    obj1 := sprite1
    obj2 := sprite2
    Renderer.CopyEx(obj1, &crop, dst, render.Angle, render.Center, render.Flip)
    Renderer.CopyEx(obj2, &crop, dst, render.Angle, render.Center, render.Flip)
    Renderer.Present()
}

Thanks!

4

Okay, that changes the play-field a bit, after my lunch break I am gonna have a quick go tour and maybe I can be useful after that, except the issue is solved in between.

-Cass

5

Do you use an IDE for go?

6

I use atom (https://atom.io/) to play with it. It recognizes go by default. You could also install some other packages to make it better (like a linter).

7

yeah, i used atom as I worked as a web developer

8

What do you use to develop with SDL?

9

I was using Emacs, then Kate for the snippets, now I use KDevelop. Did already check if there is a plugin for go, since it doesn’t look like it’s supported yet.

I am basically using snippets all the time since C support is very poor in most IDE’s except making the code colorful =) and I made my own templates for Kdev, which is good for rapid proto-typing. The rest is copied out of my code-base. I checked so many IDE’s that it’s not even funny anymore. Now since SDL2 has support for Android Studio I will try that again, when the code on my game is done. I did the proto-typing with the ndk and ant.

10

I did

import (
  ...
  "testing"
  ...
)
func BenchmarkColorMod(b *testing.B) {
	texture.SetColorMod(255,0,0)
}
testing.Benchmark(BenchmarkColorMod)

ran
go test -bench .
and got

goos: linux
goarch: amd64
pkg: colormod
BenchmarkColorMod-8 2000000000 0.00 ns/op
PASS
ok colormod 0.005s

so I would say there is no lag.
I added a timed version in c. Highest latency I measured was 4208 ns which is 0.004208 ms.
Test is here.

Cheers,
Cass

11

You have to render the texture, though. The SetColorMod itself doesn’t show any lag. I run that on the pre-load to load the textures. I render the texture a few seconds after that command has executed. That’s where you see the lag

Best regards,
Marcus