Inscription : 13 Jan 2010, 14:25 Message(s) : 2270
Longshot a écrit :
ceci dit, ça casse pas 3 pattes à un canard non plus...et il vaut mieux perdre du temps à switcher l'offset sans avoir le problème de l'écran qui démarre une ligne plus tard,et pouvoir choisir les pages switchées
Sorry if i sound how a fanboy, but i never though that one day i could talk with the CPC MASTER
I have read your comments in the thread and your explanation in the thread of Phenix Informatique, and of course, that tecnically speaking it's excessive calling "interlace", because the vertical resolution is always the same, the scanlines never half its size (now it's when Ghost thinks not very good things about me and my family , but it's interlace according to the datasheets, come on man! ), but it's no rare to talk about "interlace" when there is flickering.
When you use R8=1 (interlaced sync mode), you get between the frames odd and even a displacement of half-scanline, and the illusion looks very convincing (appears better in mode 2, how Longshot has noted) and this displacement was the same in all the CRTCs that i have tested (0,1,2 and 3, i have a CRTC 4 in the way to be functional).
And if you attached the cpc to a monitor using a scandoubler or to a TFT TV with deinterlace, it would show this pictures with 544 pixels of height without flicker, how happen with the "flipping interlace" of the zx spectrum (the equivalent to R8=0)... well i hope that looks better
Of course, everything would be different if R8=3 (interlaced sync and video mode aka "the real hardware interlace") was consisteng between all the CRTC types, but that it's not the case... and the pictures don't look so bad.
Inscription : 28 Août 2008, 23:41 Message(s) : 261
Having read the interview of the Batman team on PnP, I had to answer Rhino, and that is why I'm using English now, by hoping to dissipate any misunderstanding. I answers on this post because it is here that I wrote a stupidity which I wish to rectify.
First of all, I have never tried to minimize the impact of the demo or its importance in amount of work supplied by the whole team. I respect this huge work and I was pleasantly surprised by this production. So, greetings again.
As I have already said it on the site of NoRecess, my personal appreciation of a demo is less positive when effects use huge tables already precalculated, especially when these last ones are not generated by the demo and/or created on pc. It is my opinion, and it is not connected to BF in particular because it was also valid for demoes developed at Logon. Of course, there are several levels of appreciations according to the percent of pre-calculated datas
It is what I felt with the animations "line-to-line mpeg" which consume many disk space to display pictures Bats windows: 48k / flying component: 63k / City: 101k 292 pictures / Batman Logos: 99k 26/61 images / Cubes 77kb 120 pictures You (Rhino) ask why nobody made it before. According to me, the problem is at first that every animation consumes many bytes on disk (in BF, they represent 400 K) for very short animations) (Even if the city is very well built at this level in term of availibility of linking between sequencies to increase display time) When such a routine of video decompression exists, it becomes generic and loses of its interest in term of programming. (Demoniak moreover wrote a PC program in this spirit, at which you should look: Make3DFrame (http: // demoniak-contrib.forumactif.com/t38-mak e3dframe)) I also believe that the animations are often modelled on more powerful machines and some some of the demomakers have a "purists" philosophy (they reject what comes from the pc, and do not use cross dev, for example, but it's another subject) Finally, maybe that few programmers saw an interest to show precalculated pictures. The principle to use the modifications of the previous line to modify just the data having evolved for the current line is a known thing (Demos with parallax bars for example). From a coding point of view, it is not a complex unpacking routine (from 1 to 9 bytes(octets) by line) I imagine that the main difficulty in term of modelling of these animations was to know if they can fit in memory once compressed and certainly needs lot of adjustements (so a good knowledge of these modelling tools) I believe that these reasons explain why people did not try a lot to store this kind of animation. (Even if some people have already try do to it using another ways : midnight process, pheelone, face hugger ..)
I however made a big error of analysis by writing that rotozoom was based on this principle. I'm really sorry and i apologize for that. I can understand you was angry about my words about that. I would not have posted at once. I had considered too fast and I had not well thought about the problem. But it is not any more the case.
So, I speak now about something that I know. For the zoomscroll every scanline is generated through consequent precalculated tables (20k for the zoom table) and there is no real-time calculation. A technical difficulty consisted in interrupting at the right time the code of creation of scanlines to change crtc address according to the table zoom. It is a frequent problem when registers of the crtc evolve at variable moments. (You chose the method of the JP (IX) located by table as a replacement of POP HL (zoom factor) / ADD HL,BC) The rotozoom is more dynamic because the calculation of the addresses of every byte-pixel is real time from on a map of 256x120 bytes.
I think that it is also necessary that I clarify my comments on what I hear about "technical side", in particular in the way things were brought on PnP, and which perhaps relate the thought of other persons but not mine, because I am indirectly implicated. So that it is very clear, I did not write that BF was not "technical" because I do not think it in no way. (And there is no frustration for me (finally not that one )) Of course I think about the difficulty represented by the general cohesion between loader / music / parts and of the realization of certain parts. To be clear, when I speak about technique, as programmer, I become attached to this difficulty. I indicated that by comparing BF with From Scratch, or some other demos Cpc (which are envied on C64 too...It's another debate also). It is my opinion and it is based on my own knowledge of Z80A, the use or not of pre-calculated tables (calculated or not by the cpc) or still a management of more complex CRTC technics. R9=R4=0 is not an advanced crtc technic on cpc. (It is however a good method to avoid the problems of compatibility (with the exception of the crtc 2)) Many parts loops on loaded pre-calculated tables (offset update according to line + POP HL / ADD HL, BC / LDI zoom lines for example) I think of having clarified and explained my position now.
Inscription : 28 Août 2008, 23:41 Message(s) : 261
Hello SyX
Thank you for the comment but the cpc has other masters for a long time now.
About the interlace, I thought originally that this mode was functional and useful on Cpc. In 1988, I had spoken about it with Stéphane PICQ (author of the 3D game BIRDIE), who had already had fun a little with the crtc and the interlace. The flicking which occures when the crtc is in interlace mode can mislead On the thread of Phenix, Sylvestre had shown me that it does not work on cpc monitor, and gap between 2 frames is not 1/2 lines but 1 line (considering 312 lines/frame). A good demonstration consist to fill gradually every line linearly. We quickly see if we fill 2 lines with a color, we obtain 3 lines among which 1 more darkened. It is for that that I am surprised that you say that the interlace mode looks a movement of one 1/2 lines from a frame to the other one. The differences between crtc for the mode "interlace and video" are not really important and a little adjustment is necessary according to the crtc, but it "runs" similarly. I do not know if the problem of interlace is connected to the cpc monitor. I'm not sure about that at all. Have you tested and noticed an image of 544 different pixels in 1 frame with a TFT monitor?
@Longshot : I read what you wrote and understand your point of view. That said, I want to add common fact that lots of people tends to forget when dealing with precalculated data : it's not because your data is precalculated that it has been auto-magically generated. There is actually a big, hidden, hard work to get the right data for the right player fitting the right restrictions. Please have a read on the following page if not already done, Phreaks being my biggest work on that topic ! http://norecess.cpcscene.net/phreaks-demos-a ... ained.html
I see that you had tried to understand a little more how some effects were done. In your message there are subjective opinions (which I shall not attempt to refute, but I will give my opinion) and some incomplete technical information or inaccurate. I thought that after the interview in PnP, the issue would be settled and I had no intention to continue with technical discussions, but now is not just a technical issue. In the interview, I say that I do zoom and rotation in real time of 1450 pixels from a pre-calculated list of only 3 vertices, and now you say that there's not real time, therefore, are you calling me a liar?, you are slandering me and my work again?, ...this would be something more serious that to speak without knowledge...
Of course, you're wrong again, and you could lose all your reputation in this debate:
I will explain something about my rotozoom. When a rotozoom does not deform the ratio of the image, can take advantage of the calculation of the slope of the first horizontal line for each vertical line. This is what I do:
pop hl -> get the offset of the horizontal slope add hl,bc -> adds the offset of the vertical slope ldi -> draw pixel
Now, I think that your mistake is to believe that the data read from pop hl are pre-calculated in a long list of data calculated from a PC and 20k of size?, but NO, these data are calculated by my z80 rotozoom routine in real time in each frame, the reason to store it in memory and read it later with pop is to reuse the calculation of the horizontal slope of the first line for all vertical lines. Of course, the pre-calculated data size from a PC for the 3 vertexs to which I mean in the interview is much lower than what you say. And because you have not understood my code properly, I put here some real-time calculation code pieces that you can see at the beginning of each frame:
add hl,de ; 3c hl = y, de = (y2-y1)/w (8 bits fixed point) ld a,h ; 1c exx ; 1c add hl,de ; 3c hl = x, de = (x2-x1)/w (8 bits fixed point) ld b,a ; 1c ld c,h ; 1c push bc ; 4c (stored in mem to be reused for all horizontal lines) exx ; 1c
Note that storing in the same frame the calculation of the first horizontal slope for reuse for all lines of the frame is not "pre-calculating" but a code optimization in real time. Repeating a calculation with the same result many times is not real time merit, but stupid.
But it is useless to follow this way, Longshot, I made the effects and I know how they work really, while you must debug and look at a disassembled code, you do not know some techniques of real-time optimization, and you're confused. Anyway, I can always release my source code to refute your theories, curiously always wrong to discredit my work.
About "animations", you make everything look very simple by giving incomplete information, but this raise many questions, if only can be changed from 1 to 9 bytes per line, how is it possible to represent complex and big objects with many more changes per line and even with entire line changes (as in the case of window with bats)? If 400kb are need in disk to store only 5 effects and the other effects in your opinion are using a lot of pre-calculating too, how it is possible to put the rest of the demo in less than 200kb? Something does not quite fit into your simplistic approach...
On the other hand, I think you do a technical assessment only by the use of the CRTC, and so for you, my 3D objects are nothing new because other demos used the same CRTC technique to make parallax bars or plasma ... IMO, you have a very limited view of what you have technical merit. From your view, the routines of thousands of dots of my demo should have no any technical value, since they only use CRTC to set the overscan display or the doublebuffer, right? From your limited approach, we can draw very funny conclusions, for example, that plasmas and scrolls are much more advanced techniques than 3D objects, Zoomers or thousands of dots. The CRTC is a very simple chip compared to the Z80, the Z80 really give a lot more play to develop complex techniques, CRTC is just an additional chip to be used when necessary. Fortunately, demos can have a lot of technically impeccable effects far beyond allowing a CRTC.
Finally, I believe that using known techniques to do unknown effects on CPC, must have some value. For me more important than technical merit are the value of ideas, although I have to say that the entire CPC was unknown to me prior to do this demo.
Rhino.
Longshot a écrit :
Having read the interview of the Batman team on PnP, I had to answer Rhino, and that is why I'm using English now, by hoping to dissipate any misunderstanding. I answers on this post because it is here that I wrote a stupidity which I wish to rectify.
First of all, I have never tried to minimize the impact of the demo or its importance in amount of work supplied by the whole team. I respect this huge work and I was pleasantly surprised by this production. So, greetings again.
As I have already said it on the site of NoRecess, my personal appreciation of a demo is less positive when effects use huge tables already precalculated, especially when these last ones are not generated by the demo and/or created on pc. It is my opinion, and it is not connected to BF in particular because it was also valid for demoes developed at Logon. Of course, there are several levels of appreciations according to the percent of pre-calculated datas
It is what I felt with the animations "line-to-line mpeg" which consume many disk space to display pictures Bats windows: 48k / flying component: 63k / City: 101k 292 pictures / Batman Logos: 99k 26/61 images / Cubes 77kb 120 pictures You (Rhino) ask why nobody made it before. According to me, the problem is at first that every animation consumes many bytes on disk (in BF, they represent 400 K) for very short animations) (Even if the city is very well built at this level in term of availibility of linking between sequencies to increase display time) When such a routine of video decompression exists, it becomes generic and loses of its interest in term of programming. (Demoniak moreover wrote a PC program in this spirit, at which you should look: Make3DFrame (http: // demoniak-contrib.forumactif.com/t38-mak e3dframe)) I also believe that the animations are often modelled on more powerful machines and some some of the demomakers have a "purists" philosophy (they reject what comes from the pc, and do not use cross dev, for example, but it's another subject) Finally, maybe that few programmers saw an interest to show precalculated pictures. The principle to use the modifications of the previous line to modify just the data having evolved for the current line is a known thing (Demos with parallax bars for example). From a coding point of view, it is not a complex unpacking routine (from 1 to 9 bytes(octets) by line) I imagine that the main difficulty in term of modelling of these animations was to know if they can fit in memory once compressed and certainly needs lot of adjustements (so a good knowledge of these modelling tools) I believe that these reasons explain why people did not try a lot to store this kind of animation. (Even if some people have already try do to it using another ways : midnight process, pheelone, face hugger ..)
I however made a big error of analysis by writing that rotozoom was based on this principle. I'm really sorry and i apologize for that. I can understand you was angry about my words about that. I would not have posted at once. I had considered too fast and I had not well thought about the problem. But it is not any more the case.
So, I speak now about something that I know. For the zoomscroll every scanline is generated through consequent precalculated tables (20k for the zoom table) and there is no real-time calculation. A technical difficulty consisted in interrupting at the right time the code of creation of scanlines to change crtc address according to the table zoom. It is a frequent problem when registers of the crtc evolve at variable moments. (You chose the method of the JP (IX) located by table as a replacement of POP HL (zoom factor) / ADD HL,BC) The rotozoom is more dynamic because the calculation of the addresses of every byte-pixel is real time from on a map of 256x120 bytes.
I think that it is also necessary that I clarify my comments on what I hear about "technical side", in particular in the way things were brought on PnP, and which perhaps relate the thought of other persons but not mine, because I am indirectly implicated. So that it is very clear, I did not write that BF was not "technical" because I do not think it in no way. (And there is no frustration for me (finally not that one )) Of course I think about the difficulty represented by the general cohesion between loader / music / parts and of the realization of certain parts. To be clear, when I speak about technique, as programmer, I become attached to this difficulty. I indicated that by comparing BF with From Scratch, or some other demos Cpc (which are envied on C64 too...It's another debate also). It is my opinion and it is based on my own knowledge of Z80A, the use or not of pre-calculated tables (calculated or not by the cpc) or still a management of more complex CRTC technics. R9=R4=0 is not an advanced crtc technic on cpc. (It is however a good method to avoid the problems of compatibility (with the exception of the crtc 2)) Many parts loops on loaded pre-calculated tables (offset update according to line + POP HL / ADD HL, BC / LDI zoom lines for example) I think of having clarified and explained my position now.
Inscription : 28 Août 2008, 23:41 Message(s) : 261
I did not write that the rotozoom of BF was not real-time. I had noted what you had told in your interview. On the contrary, I allowed to have made a mistake on this point and I apologized about that.
Btw, I did not make error of analysis of the rotozoom and I had identified 29 calculations Y and 50 calculations X (you can remove all the EXX in the Y calculating (doing first the low byte of the future LD BC) to gain 58 nop) For the 20 kilobytes table, I spoke about the zoomscroll and not about the rotozoom. Concerning the animations of 3D objects (or bats), my explanations are right and not incomplete. When I spoke about parallax with the CRTC, it was in the idea that it is always the same line which is real time shown and modified From a line to the other one, the bytes to update are the ones which are modified (The shape of bats is effective for that) A black raster can possibly make you gain the time of a line. So i do not "make everything look very simple". But why want you to remind that it is more complicated than that it is in reality?
I did not say that all the parts used pre-calculated tables of more than 50 kb As i did not say the whole demo is pre-calculated. I did not say that I judged the technicality of a demo only by the CRTC If you want to set the capabilities of Z80A against the CRTC and to discuss on the idea that we cannot make a division with a CRTC, we shall agree I think that to program the CRTC (or the AY) (with Z80A, 80x86, ...) at certain levels asks a big effort of synchronization with the code (You have noticed that when you had to change offset in the middle of your code)
I like to disassemble and to understand the code of the others guys because it is instructive. I am again going to repeat it, but I did not say that BF was not technical. I recognize the merit of the innovation and thus of course the ideas which are there originally
To finish, I am not attached to a "reputation". If I make a mistake I recognize it. There are only the imbecile which always think of being right. I consider the false modesty as a wound.
Thank you for reading me better to avoid giving a bad sense to my comments or letting believe in intentions which are not mine. (And thus to react with some inequitable comments about me)
Reading your post again, I realized I made a mistake. You're talking about zoomscroll instead of rotozoom. I'm sorry but both words are very similar. But you are wrong again because the only pre-calculated data loaded for the zoomscroll are even lower than for the rotozoom. Exactly 2.640 bytes.
The principle of the real-time zoomscroll is based on that any byte of a gfx in mode 0 only has 4 possible outcomes when zoomed. So, the original font and some data are pre-processed just before the effect start to have it in a optimized way for the zoom routine, and the pre-calculated data stored on disk is only 2.640 bytes, not 20k as you said.
I understand that pre-calculating data from a PC that use a lot of disk space can be a source of complaints by some purist coders. But if you think that precalculating data (or code) in the demo just before an effect start is the same thing, is that you does not have much knowledge of fast demomaking techniques on oldschool platforms.
But I'm a little tired of having to correct your wrong analysis, so I have attached the source code of my zoomscroll + data, so you can run it from Winape by yourself and check that the font size is 3k (zsFont16_tron_red2.bin) and only 2.5k for data (zs16h.bin + zs16v.bin). Where are the 20k of loaded precadata?.
About “animations”, I see that now you admits that is not just what you said earlier, now syncronized rasters technics are also involved I think that if I continue explaining the problems of your theories we could write a huge thread here
But, about the difficulty of develop effects, IMO, there are 3 categories:
1) When you have an original idea and you apply the techniques needed to develop something never seen before.
2) When you see an effect running in a demo and you want to do it by yourself.
3) When you have disassembled the code to know how the effects was done, and then you copy it.
I did not say that my effects are the most optimized and hard to do. Indeed, in the demo, I say that is nothing compared to what others can do. But I think that the only way to understand the real difficultly of something is to do it by yourself. After all, animations are very easy to do and you are in the third category, so it should not be very hard for you... right? Maybe only when you see that any "animation" needs more than 30 changes per line, and your theory falls apart, you change your mind… until then this will be an useless debate…
Rhino.
Longshot a écrit :
I did not write that the rotozoom of BF was not real-time. I had noted what you had told in your interview. On the contrary, I allowed to have made a mistake on this point and I apologized about that.
Btw, I did not make error of analysis of the rotozoom and I had identified 29 calculations Y and 50 calculations X (you can remove all the EXX in the Y calculating (doing first the low byte of the future LD BC) to gain 58 nop) For the 20 kilobytes table, I spoke about the zoomscroll and not about the rotozoom. Concerning the animations of 3D objects (or bats), my explanations are right and not incomplete. When I spoke about parallax with the CRTC, it was in the idea that it is always the same line which is real time shown and modified From a line to the other one, the bytes to update are the ones which are modified (The shape of bats is effective for that) A black raster can possibly make you gain the time of a line. So i do not "make everything look very simple". But why want you to remind that it is more complicated than that it is in reality?
I did not say that all the parts used pre-calculated tables of more than 50 kb As i did not say the whole demo is pre-calculated. I did not say that I judged the technicality of a demo only by the CRTC If you want to set the capabilities of Z80A against the CRTC and to discuss on the idea that we cannot make a division with a CRTC, we shall agree I think that to program the CRTC (or the AY) (with Z80A, 80x86, ...) at certain levels asks a big effort of synchronization with the code (You have noticed that when you had to change offset in the middle of your code)
I like to disassemble and to understand the code of the others guys because it is instructive. I am again going to repeat it, but I did not say that BF was not technical. I recognize the merit of the innovation and thus of course the ideas which are there originally
To finish, I am not attached to a "reputation". If I make a mistake I recognize it. There are only the imbecile which always think of being right. I consider the false modesty as a wound.
Thank you for reading me better to avoid giving a bad sense to my comments or letting believe in intentions which are not mine. (And thus to react with some inequitable comments about me)
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Inscription : 28 Août 2008, 23:41 Message(s) : 261
Hi I do not consider that tables pre-calculated dynamically is the same thing as to load a mass of data stored on disk. I have already said the opposite. You should read to me again better. " For the zoomscroll every scanline is generated through consequent precalculated tables (20k for the zoom banks) and there is no real-time calculation. " I supposed nothing other things and indicated well my position on the precalculation by the demo in the interview of norecess. So I can understand that you are tired to correct me due to making errors of interpretation of my comments
It has at least the advantage to discuss about code & effects and it will interest doubtless more of one person on that site. (Cpc scene is a little scene in 2011)
For the "line-to-line mpeg", i do not admit nothing more that what I wrote "The principle to use the modifications of the previous line to modify just the data having evolved for the current line is a known thing " It supposes naturally that the code which updates the line follows the raster and modifies the line when the datas were already displayed (Too much datas to update in 64 nop and this system does not work any more, while it would be very widely perfectible on that point) Yes, i think that it is not difficult to do, but I see in no way the interest to broadcast an animation. And I'd never copied the code of another guy. Now if you want to persuade people about "30 changes per line or whatever else", it's undoubtly an useless debate
About the difficulty to code an effect, the 2) has no its place here (IMO ) When somebody sees an effect, either he tries to reproduce it by himself (with an innovative technic or not), or he copies the code (or someone explain him how to proceed) Of course, analyzing the code of a person does not imply the copy of code, or that the guy will use the same method.
On a more general idea than the technical difficulty, there are categories of people who try to redo effects (by improving them or not) and those who imagine them... But it is another debate.
Yes, I have to confess that I do not understand you very well. but I say what I think with arguments:
The rules of demomaking on an oldschool platform are clear: low speed and low memory, what do you can make with that? An effective way to make real-time routines quicker and surprising is precalculating data, so the competition of making most spectacular demos, did evolve many slow real-time routines with the usage of precalculated techniques of all kinds. But this raises a problem, and precalculating data is not always possible, because precadatas requires additional memory on disk or extra time for precalculating in the demo itself.
About my 3D objects, you say, "nice but not real-time".
I say: "Obviously, if you expect this to be possible 100% in real time is that you understand very little about the subject. But at least I found a practical and effective way to rotate 3d complex objects in overscan at 50hz on CPC that no one had done before on 8 bits. "
If you want to do everything in real time without any pre-calculated, the demos would not have evolved too much. Maybe the way you think is the reason why the CPC demos had been technically inferior to the c64 demos so far? I believe if we all think like you, we would still be in caves.
When an effect needs a lot of disk space, can be criticized on the grounds that it can have a problem of viability, because if you need lots of disk space, the demo would be too short or repetitive, as in the “All in 3d” previews for example. BF is the proof that this criticism is not always justified. Why? because when you take advantage of a concept technically more evolved than those traditionally used on CPC, as the trackmo concept, you can beat some limited memory old barriers. But when you do a demo of 11 minutes, you can only allow the use of big precadata on disk for a few effects, so I said in the interview that "if a purist coder only likes real-time orthodoxy, can remove the effects with high % of pre-calculated of BF and still get a very long demo."
BF has real-time effects, pre-calculated in the demo, and pre-calculated on disk. And this is the proof of the wide variety of techniques applied without prejudices and with the only aim of achieving the best visual possible result. You can not judge a separate effect and out of context, for example, if you need a minute of z80 precalculating time in demo to get a table of 4k, but you have 4k free on disk and takes less than 1 second in loading, it is completely justified in the context of the demo, to have those precadatas on disk. These details are very important when making a trackmo, because the sequence of effects and music can not ever stop, but you may not be aware of these problems because you have never done a trackmo like this one, and you are more interested in judging effects separately and out of context.
In any case, with the source code of the zoomscroll, I hope you learned that this effect requires very little disk space and requires very little time of preprocessing for code, gfx and data before starting the effect. So I do not know exactly what you wanted to demonstrate quoting my zoomscroll exactly.
Rhino.
Longshot a écrit :
Hi I do not consider that tables pre-calculated dynamically is the same thing as to load a mass of data stored on disk. I have already said the opposite. You should read to me again better. " For the zoomscroll every scanline is generated through consequent precalculated tables (20k for the zoom banks) and there is no real-time calculation. " I supposed nothing other things and indicated well my position on the precalculation by the demo in the interview of norecess. So I can understand that you are tired to correct me due to making errors of interpretation of my comments
It has at least the advantage to discuss about code & effects and it will interest doubtless more of one person on that site. (Cpc scene is a little scene in 2011)
For the "line-to-line mpeg", i do not admit nothing more that what I wrote "The principle to use the modifications of the previous line to modify just the data having evolved for the current line is a known thing " It supposes naturally that the code which updates the line follows the raster and modifies the line when the datas were already displayed (Too much datas to update in 64 nop and this system does not work any more, while it would be very widely perfectible on that point) Yes, i think that it is not difficult to do, but I see in no way the interest to broadcast an animation. And I'd never copied the code of another guy. Now if you want to persuade people about "30 changes per line or whatever else", it's undoubtly an useless debate
About the difficulty to code an effect, the 2) has no its place here (IMO ) When somebody sees an effect, either he tries to reproduce it by himself (with an innovative technic or not), or he copies the code (or someone explain him how to proceed) Of course, analyzing the code of a person does not imply the copy of code, or that the guy will use the same method.
On a more general idea than the technical difficulty, there are categories of people who try to redo effects (by improving them or not) and those who imagine them... But it is another debate.
Here is another example of your wrong analysis and handling:
Longshot a écrit :
According to me, the problem is at first that every animation consumes many bytes on disk (in BF, they represent 400 K) for very short animations)
Any person (including me) agree with you that wasting 400k on disk for only 5 very short effect is nonsense, a bad practice, or even cheating. So, anyone who read your lies about my demo and trust your word, may have a misconception and degraded about what BF is, my work and effort.
I made some statistics about the disk usage of BF:
Musics + sfxs:
Storm sample -> 6k window sample -> 6k logos sample -> 7k bfl sample -> 7k interference sample -> 1k intro music -> 2k main music -> 17k credits music -> 2k -------------------- total music + sfxs -> 48k
Gfxs:
startup screen -> 3k vscroll font -> 2k wayne mansion -> 10k batman sentado -> 6k bat_in_win -> 18k bg logo -> 10k credits -> 5k bfl -> 17k bf small font -> 1k bf medium font -> 2k z80bg -> 5k tunnel font s -> 1k tunnel font l -> 3k zoomscroll f -> 3k j vs b ovescan -> 13k j vs b 256x128 -> 8k twister b/j -> 2k ht bg -> 16k joker -> 5k joker zoom -> 1k batman logo -> 7k big font -> 4k hinterlace -> 33k screenshots -> 26k final screen -> 13k -------------------- total gfx -> 214k
Code + params -> about 50k (quick calculation, not exact)
The usable disk space are 200k per side, so the demo size are just under 600k. Only the code (no precadata as sinus tables.. etc..) + gfx + music + sfx are 312K aprox. Then, precadatas of the full demo on disk (not just 5 effects) are less than half the total (280k aprox), and of course, only 5 effects cannot use 400k on disk as you said. However, 280k of total precadata for a 11 min long trackmo is not so unusual. I can tell you that the best Amiga 500 trackmos use similar figures of precadata on disc.
My question is, why do you constantly give wrong information about my demo? Always wrong information that creates a wrong and degraded view of my work and effort. If it was ignorance, you were already warned that it is better not to talk without knowledge. But because your emphasis in err or handling, I do not know what to think about you.
Now you can not argue "I did not say that ...", the quote is explicit and clear, no error possible of interpretation.
How many owned are necessary until you desist in publishing false information? I don't want apologies from you again for your mistakes, I just wish not to have to refute your lies a lifetime.
I don't really think You understood what Longshot wants to tell you but you must know many people on cpc scene enjoyed and applaused your work (including all impact's team, of course)
I'm very happy to read this topics because it's a great source of inspiration for me.
I'd just want to Know what Will be your next project on cpc ? Are you waiting for some responses about bf before coding another Great demo ?
I don't really think You understood what Longshot wants to tell you but you must know many people on cpc scene enjoyed and applaused your work (including all impact's team, of course)
I'm very happy to read this topics because it's a great source of inspiration for me.
I'd just want to Know what Will be your next project on cpc ? Are you waiting for some responses about bf before coding another Great demo ?
Hi,
It is clear that he and me have very different ways of thinking.
He discredits any pre-calculation, and, for me, pre-calculating is the natural evolution of real-time to get more speed to the effects. Precalculating technics comes as a need to accelerate real-time, and thus implies an evolution. On the other hand, pure real-time does not exist from the moment you use a sinus-table, everything (or almost) is always a mixture of real-time and pre-calculated.
I also think he does not understand very well what are the technical implications of a trackmo. In a trackmo the use of precadata on disk (rather than calculated in the demo) even store graphics, music and data uncompressed is justified if that helps improve the timming of the demo. Because memory is being charged continuously while the demo runs, and it is very important to choose the quickest way to have new graphics, music, code and data in memory at all times.
He wants evaluating effects separately as if it were a one file demo, regardless of these issues and he come to erroneous conclusions. He definitely is not who to assess, but it is very bold, this does not upset me, it's funny , but I will not allow him to write lies about specifics of the demo (as info about the size of the precadatas on disk).
About your question, I do not know exactly, I'm on vacation now, but doing a demo for CPC is more complicated than I thought, first, you have to do the demo, and then the defense of false accusations. hehe
Inscription : 28 Août 2008, 23:41 Message(s) : 261
About your "3D Object", i do not say "nice but no real-time" but "nice but animation". It is not the same thing. And in this domain, "Backtro" was the first demo to have managed a "3D" animation in overscan at 50 Hz (10 years already). I do not think that the dominant criterion of a demo is to make something which runs in the frame at any price. Face Hugger megademo does not run in the frame, but I have more technical consideration for the really 3D objects of this demo The same thing with Madram and his rotozoom with real 1 pixel size. (And several others also) (They do not live all in caves (although with shap, I have a doubt)) There are many things to be made and to invent.
It is wrong to say that demos cpc were inferior "technically" for a long time than C64 (before your arrival ?). (In 1988 already Cpc made things which C64 could not reproduce, but this debate about C64 against CPC or Spectrum is an unlimited troll)
"All in 3d " is a preview. You cannot foresee its future if it had been used in a demo I would have preferred that the precalculation of the compressed data is realized on the cpc (as it is the case on Ball and Bits for example) And thus that the 3D object is really computed by the cpc It was a difference of opinion but I did not try to crush overflow... If you put 1 mn to calculate 4 k, I agree. Load from a diskette!! (They are invaluable datas) And if you think that I am against any precalculation of code or data, it is that you have never disassembled one of my demoes. (But It could pollute your mind, i've so much to learn...)
There is no relation between the programming of a trackmo and the fact of having a technical opinion on the precalculated animations It is exactly all the art of a trackmo to know how to use the cpu "timeouts" to calculate the big tables. On 11 mn, there is indeed 1mn33 of animations. But also 3mn49 of texts (including end) and drawings (And 5mn10 of effects) (By pity do not behead me if I did not well enough count but say I simply made a mistake. It's just a cpc thread) (From Scratch 88kb for 4m30 100% cpu and 33 seconds of useful "time" for precalculations) You do not certainly need my blessing if you want to think that it has so much merit but avoids bad allusions towards me and respects my opinion. For your information, the first musical loader on cpc was realized 21 years ago by Rubi. Remove the main-menu of The Demo, reducing each part to 25 seconds with some adjustments, and you have a trackmo.
I did not download your source. I spoke about the zoomscroll because I had inequitably qualified it as animation and I corrected my error by saying that it was real time managed through a precalculated table.
About your 2nd post (i see you love me), I had counted ram like that (Bat Windows: 48k / flying component: 63k / City: 101k 292 pictures / Batman Logos: 99k 26/61 images / Cubes 77kb 120 pictures) I do not know if I made an error because i've examined ram from the SP pointer. (For example cubes seems to use data ram C0=989A / C4=3A44 / C6=3FC8 / C5=EFF) This point do not create a "wrong and degraded view" of your work, because it relates only about pre-calc subject and not the rest of the demo. There is no "accusation" (it's not a tribunal) and your arrogance is tiring. If I made an error it is enough to say it to me I do not "discredit" "all" precalculation. I just said that I had less consideration for the precalculated animations and it's a mess with an aggressive trial of intention
The cpc scene is small. Few people are active and it makes debate for years. The causes are multiple and not to debate here. A good demo tempts people to be more active and it is a good thing. But try to crush the slightest opinion which is not favorable to you in 100% by trying to discredit your interlocutor denote another problem (With a sensation of already seen for what concerns me)
Well, when you began to say that the whole demo is an animation, in spite of that bothered me, I did not go to argue with you about it. I also read in many forums people say wrong things and I did not say anything. This is proof that I respect even if they are unfounded criticism, but if the PnP interview ask me, I reply. Of course, you are free to speak and call things as you want, but telling lies is another thing and is risky.
About From Scratch, all I have to say here is that is one of the best demos that I've seen on 8 bits, has an indisputable visual quality that is perceived from the first second, they have certainly managed to bring the CPC palette far beyond, getting a colorful almost impossible, everything is in one frame (as I like), they have taken great care on transitions and every detail of the demo, with the difficulty that that entails, and that only knows who did it, the graphic level is also sublime, and has some colossal moments of sync impressive effects with music, and beyond the banter and competition, I have great admiration and respect for their work, and because of this reason, I hate to technically evaluate the demo, I am not who to do so. Also, I think at first the whole demo is loaded into memory, so it is very different to BF, I think in the demo of Vanity is more important to reduce the size of the effects in memory. But making a single load demo was their choice, and I have already recommended to Hicks to do a trackmo for the next time.
Do not worry, I have not checked your info about times, but what you forgot to say is that BF rhythm is faster than that of From Scratch , and therefore, my effects are less screen time, so if you want to do comparisons would be more accurate doing a count of the number of effects .
About all the demos you quote, it is clear that I have no the CPC culture that you have, I have not seen all the CPC demos, but I speak for the comments I read in Pouet. In any case, Face Hugger megademo has all my respect for the amount of work and the context of the release date, on "Backtro" I think quite agree with Ovf approach, if you make the complicated thing, simple and visually impressive, has done something important. About other demos as Pheelone, Phearks, etc… the last thing I would say is "bah, is a video animation."
Finally, I have no interest in fighting with anybody, and all I want is that our quarrels end soon. In fact, if your answer to the interview would have been simply an apology, it would be over. But I want you to understand that is no good doing fast judgments about works that are the result of much time and selfless efforts.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 1 invité
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum