Crm32pro_ctile

 
 I am not sure how to use CRM32Pro_CTile.. It's a tileset or one tile? How do I select which tile I want is it's a tileset?

 I need some help here a.s.a.p. :) I'll keep looking over the documents..

[TheAzazel]

 Hello Mike,

this a known issue, many people ask me about the same question, right now, I dont have ready a better documentation (I will do it on coming days) but if you wish, I could send you a few examples of internal testing, at least, you could understand how to handle tiles and tileset.

Basically, follow the below code:

CRM32Pro_CTile *tMyTile=new CRM32Pro_CTile;
tMyTile->Load("file.dpf","tile name");
tMyTile->SetPosition(x,y);
// If is only a single tile:
tMyTile->Draw();
// otherwise, it has set a tileset..you must indicate what tile of the tileset
tMyTile->Draw(screen,num_tile_on_my_tileset);
delete tMyTile;

I advice you to use EditorDPF to create tileset, first one, load your image with all the tiles, select the size of each tile(of course, size x=size=y, remember they must be square) and save it to DPF.
Now, you can render it with ->Draw(screen, num_tile_on_my_tileset);

Anyway, I will send you a working example.

Hope this help you,

cheers

 
Thanks! That already helps me out a whole lot.

 I noticed there was single tile or tileset support which is great!

 I was calling Draw() like so..  (this works)

   

Código [Seleccionar] Expand

// If dead, draw dead tile, if not draw normal tile  
//index(i)->dtile->SetPosition(tx, ty);
index(i)->ntile->SetPosition(tx, ty);
index(i)->ntile->SetTileSet(0,32);
//index(i)->dead?index(i)->dtile->Draw(screen):index(i)->ntile->Draw(screen);
index(i)->ntile->Draw(screen);

 I assume SetTileSet(0,32) doesn't need to be called everytime, I just put it there to see if it worked, and it did.

I just tried your short code, and no tile was drawn on the screen. It seems without telling it it's only a  single tile and not a tileset, it wont draw. ???

 The code with your example in it (didnt work):

   

Código [Seleccionar] Expand

// If dead, draw dead tile, if not draw normal tile  
//index(i)->dtile->SetPosition(tx, ty);
index(i)->ntile->SetPosition(tx, ty);
//index(i)->ntile->SetTileSet(0,32);
//index(i)->dead?index(i)->dtile->Draw(screen):index(i)->ntile->Draw(screen);
index(i)->ntile->Draw();

??

 
Also really quick, is there no option for vertical wait retrace? (vsync) I need it for a scroller.. Without it there is some tearing, or "bunching" of pixels.

 Nevermind that last post, I took a look at the shareware copy of Raptor: Call of the shadows, and noticed they have  they ground scroll slow enough that the pixels barely "bunch", but not too slow. So I know what to do now.

[TheAzazel]

 Hi Mike,

Also really quick, is there no option for vertical wait retrace? (vsync) I need it for a scroller.. Without it there is some tearing, or "bunching" of pixels.

SDL does not support to wait for vertical retrace...I know, it is a pity... I think it will be added for next major version(aka SDL 1.3).
So, right now, there is only one way to force the vsync... when you set video mode... use SDL_HWSURFACE instead of SDL_SWSURFACE, also you need SDL_FULLSCREEN and last one and more important...SDL_DOUBLEBUF.
As you see, in Windows, this is very limited way to use vsync... you will need to use directx backend(by default), hardware surfaces, fullscreen and doublebuffer. Everything will be nice but...if you want to use alpha per pixel... the problems have reached you... directx(directdraw) does not support alpha per pixel using hardware. Once again... the future use of OpenGL backend (using glSDL) will solve this kind of problems. CRM32Pro v5.0 will use this backend...but it takes to me a few months...be patient :P

I assume SetTileSet(0,32) doesn't need to be called everytime, I just put it there to see if it worked, and it did.

I just tried your short code, and no tile was drawn on the screen. It seems without telling it it's only a single tile and not a tileset, it wont draw. ???

In theory, you dont need to call SetTileSet() if your tile is a single one... this is only to convert from normal tile to tileset and reverse... I have to investigate this issue... How do you create the tileset? using EditorDPF?
Let me know more information about this, anyway, I will try to reproduce this behaviour... and fix it of course.

Cheers!

    I've worked out how to use it, I just became confused at first glance. Thanks for your help..

 But there is a problem with CTile..  I fiddled with the editor and this is what I've come up with for CTile:

  Using a CTile as a tileset (the CTile is a tileset image) and properly added using the editor - Is slow when drawing. I don't know why, but when I used tilesets the performance went down by about 60%.

 Uing CTile as one tile works fine, no performance isssues.

 The only problem with this is I have to add every tile by hand to the dpf file.  O_O That's gonna suck.

 Does CTile work fine as a tileset when you've tested it?

[TheAzazel]

I've worked out how to use it, I just became confused at first glance. Thanks for your help..

 But there is a problem with CTile..  I fiddled with the editor and this is what I've come up with for CTile:

  Using a CTile as a tileset (the CTile is a tileset image) and properly added using the editor - Is slow when drawing. I don't know why, but when I used tilesets the performance went down by about 60%.

 Uing CTile as one tile works fine, no performance isssues.

 The only problem with this is I have to add every tile by hand to the dpf file.  O_O That's gonna suck.

 Does CTile work fine as a tileset when you've tested it?

I know that there are not enough documentation/examples about CTile. I will add an example and maybe, improve a little the documentation.

But...that slow down is very strange... in theory..using a tileset should be faster than using a lot of singles tiles!!!

In my main(and old) project, the HX, I used a lot of tileset, some maps have 4096x4096 pixels split on 64x64 tiles.. so as you see, the tileset are well tested... but maybe, due to one of the last revisions I have changed "something" that causes this behaviour.

uhmm...are you using ICursor? if so, try to discard it to test the speed improvement... maybe is something related to "auto background recovery".
If that does not work for you... let me know...

Right now, I have to test your previous issue (SetTileSet()) and this one...., Im working on config system but I could do everything! hahaha

And, forget to add every tile...it is a crazy work!, trust me, I have a fully working tileset at full power :P

cheers

 
I didn't use ICursor this time around.. (Don't need it for anything really..)

I can't figure out what would be slowing it down.. It doesn't make sense.


.. After some editing, I had tilesets working, but then I reaaranged the code to suit tilesets (alot of code changes) and its back to being f---- slow again... GAAAAAAAAAAAhhh.

 

When log is set to LOG_HIGH, everytime a tile is drawn it logs it. Since I'm drawing.. About 80 tiles every frame, not only is that stress on my old hd, but that's alot of extra work per frame _period_.

 Hehe, so I set it to LOG_NORMAL.

 All is fine now, but I will be back here posting more problems in the future  B)  

[TheAzazel]

 

When log is set to LOG_HIGH, everytime a tile is drawn it logs it. Since I'm drawing.. About 80 tiles every frame, not only is that stress on my old hd, but that's alot of extra work per frame _period_.

  Hehe, so I set it to LOG_NORMAL.

  All is fine now, but I will be back here posting more problems in the future  B)

Well done Mike!

I was like a crazy hunter trying to reproduce your issue... but yes, LOG_HIGH is only needed at development time and only sometimes to get a lot of useful information. Usually, I use LOG_NORMAL and when I finish the software, I change to LOG_LOW or even disable log output (ILogSystem.Init(..., LOG_NULL,...)).

On coming "documentation" about CTile I will add to be carefull with this issue, thanks you Mike!!

Yesterday I fixed a few minor bugs on INetwork, EditorDPF has implemented a new tab to add/modify/delete external files (if you want it, I can send you by email) and now,Im working on a XML parser...(yes! finally!).

Any problem you have...please, let me know.

Happy coding!!

 
Oo! I would like the new EditorDPF, if you have my email, email it to me!! That'd be awesome to have! I was even looking for a way to add/delete/modify/read "other" files in dpf's. Anywho, spongebob is on yo'.

Also, documentation about being careful with certain things would be cool too - It would help others not make the mistakes that I made. Hehe.

 

[Doyle33]

Set the alpha per-surface.

A surface with enabled alpha blending(per-pixel or per-surface) will be never created on video memory if alpha blending is not supported by the hardware. Right now, only glSDL supports it.
With per-pixel alpha, per-surface alpha is useless, so any attempt to activate it will be ignored.

Note that enabling and disabling the alpha blending on the execution time could slowdown your graphic performance.
To extend the information about the alpha blending,

[[EX3]]

Doyle33, this post is from 2005, i think is a very late to post a repply ;)