1) That's about pointers... I want to know how it works with bitmaps (and others images pointers). Can I use strange functions (byte, quad) to change it or load just some part of it? Like a GrabRegion, but with direct memory acess?

2) What's TMapLine for? Why doesn't TMapPoly work in v2k? Any way to get just one line of a image fast? (I want to get more than 100 lines of a image in different pointers)

3)Is Verge slow? I mean, I always worked with it, but I want an answer from a person that worked with others compilers (related do C)... I don't want to quit Verge, just know what I can do...

If you know some webpages with info about pointers and direct memory access, tell me...

---

No pointers? But without pointers, VERGE loses so much flexibility. Without direct memory access, VERGE just slips a step back towards RPGMaker. Granted most users may not understand pointers, (I get the basic idea) but I've seen the source to some advanced VC effects that use pointers heavily. Personally, I find a chain of offset pointers within an allocated memory stack to be a much better way of handling bunches of variables than using the built-ins. It just seems neater, and it does save a little memory here and there when using fewer than 32-bits. (Plus there was that weird thing with the global variables that I _wish_ I could reproduce)

VERGE is great in its ease of use, but I really think it needs the capacity to go beyond the basic. I started using 8-bit VERGE only with the understanding that it would become more advanced, which it has to a great degree. As long as those who are inexperienced do not have to concern themselves with an advanced feature, how can its inclusion be a mistake?

-Devon

---

--- Square's making money. We're making art.

Pointers in and of themselves are pretty handy for a few things, but not for high-level programming, (I personally use them here and there for interfaces only) and certainly not for a language like VC.

Instead of mangling an image via pointer access, you would have a bunch of functions that allow you to mangle said image. Tinting, scaling, skewing, etc... could all be done faster by this method than by VC control. If said methods are kept simple and flexible, then flexibility issues are minimal.

v2 is incapable of having hardware acceleration simply because DirectX and OpenGL (or more accurately, graphics hardware) have rules (or they outright forbit) direct access to image memory, for example. In my experience, complying with those rules is incredibly slow. (v2.6 has to copy the screen onto such an image surface at every retrace, hence it is noticably slower than its DOS counterpart)

Even more entertaining is the fact that making sure that a pointer is valid under v2 would be excruciatingly slow, so it isn't done. I think the result of that decision is pretty plain to see. ^_~

Finally, I've come to be very dissapointed in v2.6. It's far too unstable for its own good. The VC coder should be incapable of crashing the engine.

The one exception, I will admit, is dynamic arrays. Pointers do make them a cinch to implement. I'm still thinking about how to implement them the Right Way in VC.

---

'Never confuse a single defeat with a final defeat.' -F. Scott Fitzgerald

It doesn't quite work that way. DirectDraw uses the COM interface to give you a pointer to a surface object. The surface can be locked, and the image memory directly accessable, but it's an excruciatingly slow process. The blits, however, are potentially blindingly fast under accelerated graphics cards. (I've clocked my latest testbox at 350fps, against v2k DOS's 80 under the same situation)

OpenGL is another matter entirely. You give it some raw pixel data, and it returns a handle to a texture. This might sound more feasable under v2, until you realize that the process is similarly slow. It would be unrealistic to copy a billion textures over and over again every retrace. I don't think you can ever access an existing texture's pixel data at all, only destroy and reallocate.

My goal is to allow the engine to support any graphics API, so the only feasable way to do that is to abstract a high level interface over it. I've already done this too, and it works marvelously.

Most likely, images will be handled via integer handles, much like fonts are already. It might feel limited, until you realize that setrenderdest allows you to do many of the things that people usually use direct pointer mangling for. Lastly, this method allows the engine to keep things under control, making a FreeAllImages() command trivial.

Put simply, the interface would be simpler, safer, faster, but admittedly little more constrained, though still more than sufficient for the majority of tasks.

---

'Never confuse a single defeat with a final defeat.' -F. Scott Fitzgerald

A lot of people ask about Verge's speed. While Verge is grossly slower than a counterpart done in pure C++, most of the games made in Verge aren't very intensive anyway. If one were making a graphics engine with 16-32bit color, hundreds of sprites, special effects, and real-time 3D, you'd want to get every drop out of the processor you can. But, the 8bit graphics with a limited number of predrawn maps and sprites, Verge's lack of speed becomes almost a mute point. I have seen some games with Battle Systems with so much scripting that the game slows down significantly, but even then only when there are a lot of characters/monsters participating in the battle. Also, keep in mind that the extra time Verge takes is attributed to the time it takes to interpret the scripts, not to actually do what the scripts tell it. Therefore, doing a single graphics operation by calling one function would only take as long as C++ would take to do it plus the time it takes to interpret one line of code, which isn't much. The big slowdown in Verge when compared to C++ is when lots of calculation is involved which required Verge to interpret many statements.

---

I forgot what the original post was about. I thought you meant something else.

Sorry.

-Devon

---

--- Square's making money. We're making art.

It'll still be very possible to cram many images into one larger image, since setcliprect will remain. You would simply clip the image, then blit it. The section you want to see will be the only one visible. Moreover, you no longer have to cram all of your images in a vertical strip.

The main problem is that the engine has no idea what the images are comprised of. In a pure software driver, they could well be simple char arrays. A directdraw renderer would use surfaces, which can exist in the memory on your video card, instead of system RAM. An OpenGL driver could store them as textures to be attached to polygons. The engine simply holds on to them, and hands them over to the graphics system when they're to be manipulated.

---

'Never confuse a single defeat with a final defeat.' -F. Scott Fitzgerald

(nt)

---