MultiPut[DES],[x],[y],SRC,[xScale],[yScale],[Rotate],[Trans]

[Adigun A. Polack]

D.J.Peters, upon further testing of your new code indeed, I just discovered a bug tonight in which the *final* vertical scanline of any graphics mode is missing! Let me show you:



So, what you need to do on your new code is to change this line:

Code: Select all

if xEnd>=TargetWidth then xEnd=TargetWidth-1

....to this:

Code: Select all

if xEnd>=TargetWidth then xEnd=TargetWidth

....so that at runtime, man, the result will be like this:



You see the difference? ^-^=b

And finally, you forgot to place:

Code: Select all

ImageDestroy Sprite

....just near the *very* end of your program, so put it in there if you want to safely remove your sprite from memory, ok now? :D

Thanks once again, and I am so glad to help you, D.J.Peters!! Chao!!! (^-^)v

[D.J.Peters]

Thnx for new testing i don't know why U or V can be smaler than 0

I can't acept this test for every pixel :-(
if u<0 then u=0
if v<0 then v=0

Joshy

[D.J.Peters]

Hello Adigun A. Polack,
if ScreenWidth is 640 the Last pixel is 639 renember first is 0 not 1

if xEnd>=640 then XEnd=639
same as
if xEnd>=TargetWidth then xEnd=TargetWidth-1
seams to be ok for me. ( i will test it.)

FB allocates memory with the C API if the prozes ends all memory will be free without an call to deallocate.
An program without an bug don't need any call to deallocate. (trust me)
But it looks nicer with deallocate. Feel free and use it.

Joshy

[marzec]

uhm sorry this is not entirely true from what i know. deallocating your memory is still a must even though the os might decide to free the memory. many os' do a good job on that part, some on the other hand #%$@ up. also, say you got a game and you load like 150mb per level for 3d data, textures etc. not freeing that memory will make your users machine go boom at level 10 most likely :p

ppl DO deallocate your memory!

[Nodtveidt]

An program without an bug don't need any call to deallocate. (trust me)

Yep, I trust you...I trust that you'll leave my computer's memory in shambles with this kind of advice. Dude...do you have any idea what kind of mess skipping deallocation creates?!

[D.J.Peters]

Hello marzec,
if an process ends (without an crash) all memory will be freed from the OS.
The OS is the master of the loading task and adjust all needed selectors and local/user memory tables.
I can watch it with WIN98SE,Me,XP Linux 2.4 and 2.6 kernels too.

The same for FreeLib

Please give me an example that memory will not be freed after an END statment.

Joshy

Sorry if i wrong.

[Nexinarus]

Like if you allocate memory with pointers etc, it's vital as a programmer to deallocate the memory once you're finished with using it.

[stylin]

ppl DO deallocate your memory!

Q.F.E.

Additionally, whether or not all allocated memory in a FreeBASIC program is freed upon exit or not, it's beyond good practice to free memory manually.

1. it builds better programming habits.
2. not knowing what, where and how much memory is reserved increases the chances of letting it get out of hand, and crashing - deallocate(...) does more than make code look nice (this applies more to already freed memory, but the principle applies here as well: don't leave it up to the system to handle your memory - you are the programmer, not the OS)

When FreeBASIC supports classes, you can use destructors to handle much of the memory management automagically, but ... it doesn't yet.

Sorry for the hijack.

[D.J.Peters]

Hello stylin,
you don't need to wait for OOP i use destructur since 0.14

Joshy

Code: Select all

public sub _SUI_EXIT() destructor
dprint("_SUI_EXIT")
  with Info
    if .ThreadID<>NULL then
      .ExitThread=True
dprint("ThreadWait")
      ThreadWait .ThreadID
    end if
    if .MutexID<>NULL then MutexDestroy .MutexID
  end with
  if MemoryPtr<>NULL then Deallocate MemoryPtr
end sub

[stylin]

you don't need to wait for OOP i use destructur since 0.14

Cute, but I was referring to situations during run-time (not just at program exit). FreeBASIC's constructor and destructor functions are good for basic, catch-all garbage collection (at program exit), true. But the majority of memory management problems don't arise from garbage collected on exit. (ie, they are the cause of the garbage)

[D.J.Peters]

Now i know what you mean.

Joshy

[axipher]

Dealocating memory isn't only a problem at program end, just say you have a game that goes in levels, and each level has it's own sprites, allocating all your sprites and not dealocating them after each level can cause memory to be used up when it doesn't have too, this can increase system requirements, just thought I'd point that out.

[stylin]

Good job, axipher. ;)

[axipher]

Good job, axipher. ;)

Thanks alot, this week I was at my uncle's, he has High Speed, and 119mb RAM, yes 119, so I'd go to play different games online and it loads all the models at the begining and doesn't free them when there uneeded, so reading this topic solved my problem, so I posted. I'm sure the same thing has happened to some of you too.

[Lachie Dazdarian]

Wow, Joshy! What a brilliant routine! Especially great for those who have no idea how to code it by themselves, like me. It's in a form of a sub, it's reliable, easy to use and versatile. I tried it in different resolutions and with images of different sizes. It works like a charm. Funny, but I was just looking for something like this. It will work great on few places in LONG. Thank you 1000 times.

P.S.

Perhaps you should consider to present this routine in a form of a tutorial
for QB Express. So pathetic coders like me can at least grasp how it functions.