Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / [LOCKED] image from memblock

Author
Message
Flashing Blade
22
Years of Service
User Offline
Joined: 19th Oct 2002
Location: United Kingdom
Posted: 14th Feb 2003 14:05
Link
is this a bug or am i stoopid? :



bitmap from memblock is ok:



is image->memblock buggy or am i not understanding something

Last question - the reason i messing with memblocks is so i can make a good sprite collision function, 'cus sprite hit() and sprite collision() rather useless. My question is will patch 4 make sprite collision pixel perfect?
Back to top
Profile PM Email Website
mimesis
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: Norway
Posted: 14th Feb 2003 14:29
Link
@Flashingblade
If u convert an image to memblock and then delete it, u must
convert the memblock back to image before using it.

use: make image from memblock 1,1
before: paste image 1,300,20
Back to top
Profile PM
Richard Davey
Retired Moderator
23
Years of Service
User Offline
Joined: 30th Apr 2002
Location: On the Jupiter Probe
Posted: 14th Feb 2003 14:30
Link
The problem is that you're deleting the image after you make a memblock from it.

Why is this a problem? because "make image from memblock" requires that the resource actually exists. I.e. image 1 needs to exist because what the command will do is overwrite the image data with the contents of the memblock. It does not "create" the image automatically for you.

So basically either don't delete the image or perform a "get image 2,..." and use that when you write the memblock out again.

Cheers,

Rich

"Gentlemen, we are about to short-circuit the Universe!"
DB Team / Atari ST / DarkForge / Retro Gaming
Back to top
Profile PM Email Website
spooky
22
Years of Service
User Offline
Joined: 30th Aug 2002
Location: United Kingdom
Posted: 14th Feb 2003 14:32
Link
freddix has already done a perfect sprite collision routine with memblocks, if you are interested:

http://http://www.darkbasicpro.com/apollo/view.php?t=4826&b=6

I love it when a plan comes together
Back to top
Profile PM Website
Flashing Blade
22
Years of Service
User Offline
Joined: 19th Oct 2002
Location: United Kingdom
Posted: 14th Feb 2003 14:42
Link
thanks for your help

@bassi
i did make image from memblock before i pasted it

@rich
yep that works - if i don't delete the image it works. 1 more thing: if i make a 24bit image in an art prog then save it as 24bit bmp then load it into dbp as image then set display in dbp to w,h,16 and make memblock from the image, how come the memblock is 32bit?

@ ne1 who'll listen - will patch 4 improve sprite collision detection?
Back to top
Profile PM Email Website
Flashing Blade
22
Years of Service
User Offline
Joined: 19th Oct 2002
Location: United Kingdom
Posted: 14th Feb 2003 14:46
Link
@sonic - thanks i gonna try to make my own function 1st. But if i fail i will check out that link.
Back to top
Profile PM Email Website
Flashing Blade
22
Years of Service
User Offline
Joined: 19th Oct 2002
Location: United Kingdom
Posted: 14th Feb 2003 14:52
Link
forget my question about 24 bit/32bit i just realised my mistake (stoopid me)
Back to top
Profile PM Email Website
Richard Davey
Retired Moderator
23
Years of Service
User Offline
Joined: 30th Apr 2002
Location: On the Jupiter Probe
Posted: 14th Feb 2003 14:54
Link
Everything is 32-bit internally in DBPro

And no Patch4 doesn't address pixel-perfect sprite collision, it's a DBO engine release mostly (and always has been). Hopefully Patch5 will.

Cheers,

Rich

"Gentlemen, we are about to short-circuit the Universe!"
DB Team / Atari ST / DarkForge / Retro Gaming
Back to top
Profile PM Email Website
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 14th Feb 2003 15:16
Link
hmm... so its because he's using the "get image" command rather than loading an image right?
i mean cause i remember when i put an image into a memblock that the data is there, and if i want to put it back as an image i have to delete the original image.



Tsu'va Oni Ni Jyuuko Fiori Sei Tau!
One block follows the suit ... the whole suit of blocks is the path ... what have you found?
Back to top
Profile PM Email Website
mimesis
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: Norway
Posted: 14th Feb 2003 15:29
Link
@Flashingblade
Sorry, I missed your make image from memblock command

Correct me if I'm wrong but is it so that the parameters
for 'make image from memblock' are in the wrong order?
or is it the 'make memblock from image' command ?
Back to top
Profile PM
mimesis
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: Norway
Posted: 14th Feb 2003 15:32
Link
'Create Image ImageNum,width,height' would be an useful
command for creating empty images on the fly without the
need to grab a new one from bitmap, just a suggestion.
Back to top
Profile PM
Richard Davey
Retired Moderator
23
Years of Service
User Offline
Joined: 30th Apr 2002
Location: On the Jupiter Probe
Posted: 14th Feb 2003 16:18
Link
Raven - it's not the fact he deleted the original image that is the problem, it's the fact he doesn't have an image for the memblock to overwrite. The command doesn't care what the image contains, it blanks it totally from whatever is stored in the memblock, it just needs the resource to actually exist.

Bassi - no, the parameters are the right way around in both cases. I agree that a "create image" command would be very useful. It doesn't need the width/height parts if you're going to overwrite it from a memblock though because they will be reset.

Cheers,

Rich

"Gentlemen, we are about to short-circuit the Universe!"
DB Team / Atari ST / DarkForge / Retro Gaming
Back to top
Profile PM Email Website
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 14th Feb 2003 17:39
Link
oki i'm thouroughly confused now...

You have the image object right, so its like;
Image Object -> Memblock Image

but the Memblock image isn't real, its just the memory allocation of the image in question?
so if you Delete the Image Object, then you're also deleting the Memblock's data?

this would make a little more sense about a few things, but say you then copied the Memblock to another Memblock - would it still be a pointer or would that be a real memory block?

Tsu'va Oni Ni Jyuuko Fiori Sei Tau!
One block follows the suit ... the whole suit of blocks is the path ... what have you found?
Back to top
Profile PM Email Website
Richard Davey
Retired Moderator
23
Years of Service
User Offline
Joined: 30th Apr 2002
Location: On the Jupiter Probe
Posted: 14th Feb 2003 17:51
Link
Heh.. nope

Ok here is how it works:

1) Load (or Get) an image

2) Use "make memblock from image"

3) This creates a memblock which contains all of the image data that was in your image (32-bit format, see the manual for the layout)

4) This new memblock and the original image are not associated or linked in any way at all. If you delete the original image, scale it, flip it, whatever - it doesn't effect the memblock. The memblock simply contains a copy of that image at the point in time at which you "make" it.

5) In order to get the memblock back into an "image" (as far as DBPro is concerned) again you need to give it a resource for it to dump all it's data into. This resource should have been created in advance (via either "load image" or "get image").

You can quite legally do "get image 2,0,0,1,1" and THEN do "make image from memblock" and that image could be 512x512 in size - it doesn't matter, it will overwrite the image. What the command needs is the RESOURCE to exist because it cannot create one itself.

Every time you load/get an image into DBPro it creates an internal object/resource and it's this that you are operating on.

6) If you do a "copy memblock" it's doing exactly that - copying the data itself. Once copied the two sets of data are in no way linked or associated with each other. It's quite literally a copy of data from one area of memory to another.

I think you are getting it confused with pointers, they are an entirely different issue - they POINT to areas in memory (as opposed to actually containing that data) and are referenced with the * character by a variable name.

For example if you had a string called raven$, using the pointer control would allow you to get the exact location in memory of that string. Once you know the location, you could manipulate (or more likely) copy the data elsewhere. Pointers are useful because things move around in memory the more your program runs. They're not what we're using here though

Cheers,

Rich

"Gentlemen, we are about to short-circuit the Universe!"
DB Team / Atari ST / DarkForge / Retro Gaming
Back to top
Profile PM Email Website
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 14th Feb 2003 19:22
Link
not really... its just confusing that you have to have an object already available to associate the memblock -> image, especially as i remember in DarkBasic Enhanced if you tried that it'd give you an error because the object/image already exists

i don't understand why that appears to have chamged

i mean if i understand this right

image object -> memblock image

now memblock image is complete data set, and image object is also the data set...

but when you go make image from memblock, the number provided must be an already existing image ...

so image object <- memblock data

as it relies on needing an already available object rather than creating a new one, it would make no sense unless it was a data pointer
effectively you've given the information within the image to edit, but is a copy of the data within a memory space - this is probably whats confusing me here.

Tsu'va Oni Ni Jyuuko Fiori Sei Tau!
One block follows the suit ... the whole suit of blocks is the path ... what have you found?
Back to top
Profile PM Email Website
Richard Davey
Retired Moderator
23
Years of Service
User Offline
Joined: 30th Apr 2002
Location: On the Jupiter Probe
Posted: 14th Feb 2003 19:33
Link
Yes it is different from DBEP and for good reason - this way is far more flexible.

Think about this scenerio:

You have a memblock containing an image that you're going to perform an effect on (say a blur or colour change or something).

You want to display these changes on-screen, but these changes are going to happen real fast - say every sync.

Using the old method you'd have to create a brand new image every single sync because in order to output your modified image data from the memblock it'd error if you try and dump it in an image that exists.

Using the DBPro way you can modify, dump out, modify, dump out, etc as fast as you like (and it is fast, VERY fast) which means you can perform realtime pixel effects on any memblock image and use them properly.

The only thing that could be done to make it more useful is if the image doesn't exist, it creates it for you. But that's it - this method is still far better than before.

It needs an object/resource to already exist in order to dump out to, but it wouldn't use a pointer for this for the simple reason that the resource has its own data. You need to change that data, not link it to a memblock - that would get exceedingly confusing.

Trust me, it's more flexible this way.

Cheers,

Rich

"Gentlemen, we are about to short-circuit the Universe!"
DB Team / Atari ST / DarkForge / Retro Gaming
Back to top
Profile PM Email Website
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 14th Feb 2003 19:58
Link
but the resource isn't being used any differently

i mean think about if you take the memblock, now if the data isn't a pointer to the object memory space - Pro is still recreating the data within the memory else where as part of the memblock.

it is then "dumping" as it were the entire information within the object in question - so really the make image command has been changed into a pointer which needs to be attached to an object.
So rather than recreating the object again, its simply point this object to the new data ... however if this isn't the case then its still copying all the data back - which is just as slow as making a new image
the only difference is the memory is pre-assigned for the image which is only an increase in speed if the memory space allocated and the space required is identical or less.
if you use a greater space then the whole allocation system has to rearrange things to fit causing a slowdown.

would be better to have 2 functions for this
Ptr Image from Memblock [image],[memblock]
Make Image from Memblock [image],[memblock]

the Ptr one will "dump" the information as it were for editing existing images, whereas the Make will actually make the new image object
that way you won't have to create the new resource if you never created the memblock from one in the first place

Tsu'va Oni Ni Jyuuko Fiori Sei Tau!
One block follows the suit ... the whole suit of blocks is the path ... what have you found?
Back to top
Profile PM Email Website
Richard Davey
Retired Moderator
23
Years of Service
User Offline
Joined: 30th Apr 2002
Location: On the Jupiter Probe
Posted: 14th Feb 2003 20:14
Link
But don't you see? You can already do that.

If you want to just edit the data of an image directly (without using memblocks at all) then use a pointer and get manipulating!

If you want to keep the image data within the memblock then do it the way I suggested before.

Copying data from an existing memblock to an existing resource is most definitely not as slow as creating an entirely new resource for the purpose. Think about all the data structures that are in place for tracking every single resource within DBPro each time you make one. Quite a lot! Performing a direct memory copy is extremely fast when all of these things are already in place even if it means allocating extra bytes on the end.

Cheers,

Rich

"Gentlemen, we are about to short-circuit the Universe!"
DB Team / Atari ST / DarkForge / Retro Gaming
Back to top
Profile PM Email Website
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 14th Feb 2003 20:31
Link
yeah but it still requires you have a presetup resource ... which if you setting it up just to use it in the first place is quite annoying, especially as it was never originally documented this way.

i can see the point in using the memblock in this way, but is isn't really "making" anything it is simply copying the data into a premade structure. would be better within a new function, would also be better for legacy support that way.

Tsu'va Oni Ni Jyuuko Fiori Sei Tau!
One block follows the suit ... the whole suit of blocks is the path ... what have you found?
Back to top
Profile PM Email Website
Richard Davey
Retired Moderator
23
Years of Service
User Offline
Joined: 30th Apr 2002
Location: On the Jupiter Probe
Posted: 14th Feb 2003 20:44
Link
"yeah but it still requires you have a presetup resource"

True - but seeing as you can't actually use the "make memblock from image" command without the resource already existing - that's not really a good enough reason is it

Hello chicken, meet the egg

If you want to scramble your egg before you get a chance to write your new chicken out to it again - hmmm, that's your problem!

Cheers,

Rich

"Gentlemen, we are about to short-circuit the Universe!"
DB Team / Atari ST / DarkForge / Retro Gaming
Back to top
Profile PM Email Website
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 14th Feb 2003 20:53
Link
not really... because for KG's format i'm not loading an image memblock from an image - i'm creating it in the form of an image memblock so it can be used as an image object.

i do have a version here i was gonna give to KG, but i have to go through it and edit it to create and assign image objects else it wont work. it is kinda annoying and does take from the DarkBasic Enhanced compatibility.

Tsu'va Oni Ni Jyuuko Fiori Sei Tau!
One block follows the suit ... the whole suit of blocks is the path ... what have you found?
Back to top
Profile PM Email Website
Richard Davey
Retired Moderator
23
Years of Service
User Offline
Joined: 30th Apr 2002
Location: On the Jupiter Probe
Posted: 14th Feb 2003 21:14
Link
Sorry but that doesn't make much sense. Perhaps if you tried using the commands as they exist in the way they exist without re-inventing the wheel and wondering why it comes out square shaped things might be a bit easier.

I can't believe for a second you got so far through your program without realising it didn't work! It might not be the same as DBEP but I'm quite thankful for that, it's far more powerful now.

Cheers,

Rich

"Gentlemen, we are about to short-circuit the Universe!"
DB Team / Atari ST / DarkForge / Retro Gaming
Back to top
Profile PM Email Website
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 15th Feb 2003 00:06
Link
i'm not compileing as i code because it requires me to boot up another machine, check to see if the net connection is working - if it isn't then i have to find a CDRW to copy it across, and its all a performance so i only compile when i have enough for it to be worth debugging. I'm still using primarily DarkBasic Enhanced, and working with the Enhanced mindset - just updating the code to utilise the Professional commands.

and i'd hardly say i'm reinventing the wheel its just a format importer/exporter.
for a format importer/exporer it not a format recognised by DBpro - so i'm loading it via the file commands into a memblock laying it out as an image object so that i can just use the make image from memblock so it'll load directly rather than having to export the file again in a format Pro does recognise
therefore there is no prior image object for it.

and i'm not saying it should ALSO have this way, but it'd of made more sense to have it as an additional command rather than the same command, or atleast automatically check to see if the image already exists so it can just copy rather than create.

i mean the whole hoohar about keeping with DarkBasics language set was primarily for back compatilbility, so it seems strange to alter a function in such a way that it makes all Enhanced code that used it useless without simple editing

does seem somewhat hindsighted to setup a new way of using an option and have the product noting about the back compatibility cause it just isn't the case is it?
i really don't want to have to try to remember whenever i'm using either Enhanced or Pro which setup i'm to be using, how i'm to be coding things - else what is the point in keeping the old language ...

i'm begining to feel i've wasted a good portion of the day, and i'm begining to wonder what other commands have been altered to be "better" resulting in the strange results that we get when we want to compile.
by all means extend and enhance the language but not at the cost of compatibility of this nature - its confusing enough without neaunce differences.

Tsu'va Oni Ni Jyuuko Fiori Sei Tau!
One block follows the suit ... the whole suit of blocks is the path ... what have you found?
Back to top
Profile PM Email Website
Flashing Blade
22
Years of Service
User Offline
Joined: 19th Oct 2002
Location: United Kingdom
Posted: 15th Feb 2003 02:07
Link
man i still having trouble making memblocks

If i make a memblock from an image then paste image and get image and make memblock from new image(which is exact copy of origional image) - memblock 1 and memblock 2 should be same but they aint.

What i trying to do is this:
pass 2 sprite numbers to function
make memblock 1 from smallest sprites image
make new bitmap
paste sprite 1's image at sprite 1's x,y
paste sprite 2's image at sprite 2's x,y
get image using smallest sprites x,y,x+width,y+width
make memblock 2 with new image i just grabbed
loop from 12 to length of memblock and check if any of bytes are different
if they are then check bytes left and right and up and down to make sure they not black - if not black collision and exit function - if they are black then continue with loop
i not got to work on my loop yet 'cus memblock 2 and memblock 1 totaly different.

so i did a quick test and made a sprite from image i grabbed to make memblock 2 - the image was bigger than origional.

so not memblocks problem it's either get image or paste image

from this i think its get image:



why are all 3 circles not same?

thnx in advance for any help
Back to top
Profile PM Email Website
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 15th Feb 2003 02:15
Link
Use 'GET IMAGE 1,50,50,200,200,1'. This deactivates anti-aliasing.
Back to top
Profile PM Email Website
Flashing Blade
22
Years of Service
User Offline
Joined: 19th Oct 2002
Location: United Kingdom
Posted: 15th Feb 2003 02:25
Link
ty IanM
that info not in manual - it's on F1 though
Back to top
Profile PM Email Website
Flashing Blade
22
Years of Service
User Offline
Joined: 19th Oct 2002
Location: United Kingdom
Posted: 15th Feb 2003 12:50
Link
ty all i made my function (i put it on code snippets forum)
had to use make memblock from bitmap 'cus memblocks from loaded images were not same as origional images???
Back to top
Profile PM Email Website
Draez
22
Years of Service
User Offline
Joined: 1st Nov 2002
Location:
Posted: 17th Feb 2003 21:02
Link
Programming is all about moving onward and upward. I side with rich on this one. If you want to reep the benefits of performance then sometimes you have to change your way of thinking. There have been several programs I've written in the past that I look back on and would have done completely different if only to make it faster. This is a programming language and as such may need to change in function and design from time to time to make it faster. Do you really find it that much of a problem to read the manual and adjust the code accordingly to reap the rewards of having a faster running end product for the customer? And if you do, why would you want to use Dark Basic Pro. You seem to be happy with your version. From what I've read you don't even have a full version of pro. So why not just stay with your current version? I'm sure Pro will have new features and you would actually have to read about them and add code to make it work so either way you would have to change code accordingly. Seems to me that you just want to pick fights with the admin.

Back to top
Profile PM
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 17th Feb 2003 21:22
Link
i actually have a copy of professional at home, however for the past 3months i've been back in the UK sorting out some family business, and have order a second copy - yet not arrived yet.

that aside... i understand a language should move on, but to be claiming legacy compatibility then changing the core commands rather than either adding said support or adding a secondary function IS stupid.

if they're going to change functions which you expect to work a certain way from DarkBasic Standard/Enhanced, without clearly documenting the changes yet documenting that althought Professional is a new system its still aimed to be 100% compatible with DarkBasic Standard/Enhanced ... well surely doing this would actually make them out to be liers, no?

i can understand the benfits from just moveing a chunk of memory to provide this service, however not at the cost of utilising a language the way we've been doing so for several months. If this has happened with more than just a few commands i think this would actually make more sense all the "bug" reports.

personally i'd prefer a second command so i can choose which technique to use, as there are more reasons than just internal use that you might want to create an image memblock ... and by instead of adding a command for this or extending the commands use (i.e. if you have the resource it uses it, else it'll create one) they're just breeding the confusing between the languages.

Personally i'd prefer 100% compatibility between the languages before any new functions as this is what we were promised over a year ago!!

they can extend and add commands all they like to enhanced the language as long as when i plug in a command normally it will work identically to its DarkBasic 1.1x counterpart!

and just because i don't have a full professional version with me doesn't mean that i'm not developing alot of things for those with professional themselves, it just means i can't compile and expect the exact same results... so i have to code more robustly unfortunately - and then enhance speed in the next month when i finally do get home and back to my own development platform.

since being told a few things they've been niggled into Ciyanna so i don't have to worry about this myself, but it is getting annoying patching my IDE just to support all the differences between languages which are suppose to be fully compatible

Tsu'va Oni Ni Jyuuko Fiori Sei Tau!
One block follows the suit ... the whole suit of blocks is the path ... what have you found?
Back to top
Profile PM Email Website
Draez
22
Years of Service
User Offline
Joined: 1st Nov 2002
Location:
Posted: 18th Feb 2003 05:24
Link
I can see your point but given the choice between having to recode some parts and gain speed vs having compatibility between versions and not gaining speed I would take the former for the sake of the product and the customer.

Back to top
Profile PM
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 18th Feb 2003 07:18
Link
i wouldn't ... the promise was made for the product to be as compatible as possible, and obviously they're word has been broken by changing such a function without recourse.

i'm not saying the extra speed isn't good, what i'm saying is changing something and then not documenting the change whilst saying its being developed for max compatibility - i dunno thats whats kinda pissing me off here.

and i'd still prefer either two functions for this, so i know which one i'm using - or the compatibility extention added for the command to be compatible.
Also the names of the functions are there to be descriptive ... and "Make Image from Memblock" is no longer an acurate description, it should be "Copy Image Memblock to Resource" or something like that - as its no longer making the image object

i'd like to know how many of the other functions have been changed for the "better" without documentation, because i'd hate to spend alot of time coding something just to find out it doesn't bloody work cause the functions setup has changed.

i've got a long day ahead of me checking all these commands to find differences between the original, simply because there is no heads-up documentation for DarkBasic users ... i mean why should i have to sit here and check out every function i'm going to use in a manual after i spent the past year learning a way to use it already, then having to remember which way i'm using it for which language because i'm not going to exclusively use professional simply because i have it - i mean i have C++ 6.0 and .Net doesn't mean i wanna use .Net over 6.0, infact i rarely do because of compatibility issues with functions and operating systems.

Tsu'va Oni Ni Jyuuko Fiori Sei Tau!
One block follows the suit ... the whole suit of blocks is the path ... what have you found?
Back to top
Profile PM Email Website
Richard Davey
Retired Moderator
23
Years of Service
User Offline
Joined: 30th Apr 2002
Location: On the Jupiter Probe
Posted: 18th Feb 2003 10:50
Link
We never once claimed it was 100% compatible - hell, even the box it comes in says that programs will not run without modification. A vast number of commands have changed. Don't waste your time "comparing them all" because it's obvious you didn't even check your code (I still don't buy that btw) so I'm not sure what benefit it would be.

If you read the manual it tells you what you need. It might not say "this is different from DBEP" but it DOES tell you what is required.

Wether you choose to ignore that or not is another matter.

"i mean i have C++ 6.0 and .Net doesn't mean i wanna use .Net over 6.0, infact i rarely do because of compatibility issues with functions and operating systems."

You have DB and DBPro, doesn't mean you wanna use DBPro over DB. Infact you rarely do because of compatiblity issues with functions.

Perfect example, thank you.

Cheers,

Rich

"Gentlemen, we are about to short-circuit the Universe!"
DB Team / Atari ST / DarkForge / Retro Gaming
Back to top
Profile PM Email Website
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 18th Feb 2003 19:35
Link
yes... but unlike C++ 6.0 and .Net where there are minor speed changes, the speed changes between DB and DBpro is just unbelievable.

If it was just a matter of a few FPS i wouldn't really care, but you're talking the difference between Quake Content and Quake3 Contant!!

there are just so many functions within Professional, its hard to read up on them all - and to be honest shouldn't need too should i?
we've already learnt the language once, now we have to learn it again for using pro? that doesn't seem just a bit senseless?

i know alot of programmer here sit there with their manual on the table and flick throught it every chance, but i've tried to remember as many functions as possible so i can code without stopping every 5mins, checking the manual and carrying on.

i'd of prefered a full language change so i'm learning a completely new language/function set to the same functions with different meanings...
its like learning Belgian after i've learnt French, the languages are similar - but i'm likely to end up insulting someones mom if i don't stop and check a meaning of the more complex works every now and then.

for me atleast its harder to remember subtle differences than an entirely new setup.

Tsu'va Oni Ni Jyuuko Fiori Sei Tau!
One block follows the suit ... the whole suit of blocks is the path ... what have you found?
Back to top
Profile PM Email Website
Shadow Robert
22
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 18th Feb 2003 19:42
Link
i've got other examples... like

#include - did you know that if you add a file in the IDE for Professional, if you ALSO use the #include command it crashes professional?

why because this function is there for legacy compatibility, yet whats the point? we shouldn't need to modify code for above versions for it to work perfectly - however we should modify the code for prior versions.

the whole point in pro was the speed gained from making a compiler version of the language no?
it would make more sense to start with remaking Standard, moving onto Enhanced and then finally enhancing upon that - so when moving up we don't have to sit there and learn new language setups, all the little changes and we can simply take our original code ... pop it into Pro and et voila it compiles fine.

thats how it should be, instead DarkBasic code requires editing prior to compiling (which can take hours with large code) and DarkBasic Pro code isn't 100% compatible with itself.

either drop the DarkBasic compatibility to make Pro stand on its own and increase the Pro compatibility, or put the Pro stuff to the side whilst improving the DarkBasic compatibility... doing both is going to just breed more and more bugs - which is getting very very annoying.

because bugs which can be fixxed i can live with, bugs because of function changes ... THAT is what is pissing me off!

Tsu'va Oni Ni Jyuuko Fiori Sei Tau!
One block follows the suit ... the whole suit of blocks is the path ... what have you found?
Back to top
Profile PM Email Website
Richard Davey
Retired Moderator
23
Years of Service
User Offline
Joined: 30th Apr 2002
Location: On the Jupiter Probe
Posted: 18th Feb 2003 20:11
Link
Is your F1 key under your desk also? I don't know anyone who uses their paper manual considering it's all in there in its context-sensitive loveliness.

"we shouldn't need to modify code for above versions for it to work perfectly"

If we'd said from the start "100% compatability! No need to alter ANY code at all!" then I would agree. But we didn't. Ever. Not once. Am I making myself clear yet?

I'm not going to keep on and on repeating myself, you obviously have a bee up your ass about this change. Things work they way they do for a reason regardless of if that reason gets past your blinkers or not.

I'm locking this thread, its reached pointlessness - just a merry go-round of opinion. You've had your answer, GOIAGU.

"Gentlemen, we are about to short-circuit the Universe!"
DB Team / Atari ST / DarkForge / Retro Gaming
Back to top
Profile PM Email Website
Back to top

Login to post a reply

Server time is: 2025-05-18 04:57:29
Your offset time is: 2025-05-18 04:57:29